https://bugs.documentfoundation.org/show_bug.cgi?id=166108
Ivana Gyro <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WORKSFORME |--- Ever confirmed|1 |0 Status|RESOLVED |UNCONFIRMED --- Comment #11 from Ivana Gyro <[email protected]> --- I can reproduce both this issue and the closely related behavior discussed in bug 166108 / bug 164862 on Windows 11. I investigated the Windows file associations in more detail, and the two issues appear to be related. ## Environment * Windows 11 * LibreOffice 26.2 * Standard desktop installation under: `C:\Program Files\LibreOffice` The issue is reproducible with `.odt`. ## 1. There are two different ways Windows can associate `.odt` with LibreOffice Writer Windows presents both a LibreOffice association and a LibreOffice Writer / `swriter.exe` association. I queried the effective association using the same Windows API used by LibreOffice: ```cpp IApplicationAssociationRegistration::QueryCurrentDefault( L".odt", AT_FILEEXTENSION, AL_EFFECTIVE, ... ) ``` ### When selecting the LibreOffice-registered entry Windows reports: ```text LibreOffice.WriterDocument.1 ``` LibreOffice accepts this as the default association and does not show the “Default file formats not registered” notification. ### When selecting LibreOffice Writer / `swriter.exe` Windows reports: ```text Applications\swriter.exe ``` The `.odt` file still opens correctly in LibreOffice Writer, but LibreOffice shows the “Default file formats not registered” notification. This matches the current check in: ```text vcl/win/app/fileregistration.cxx ``` which expects: ```cpp { L".odt", L"LibreOffice.WriterDocument.1" } ``` and compares the effective ProgID returned by `QueryCurrentDefault()` against that string. Therefore: ```text LibreOffice.WriterDocument.1 ``` passes, while: ```text Applications\swriter.exe ``` fails, even though the latter is LibreOffice Writer and is the actual effective default application. This explains the notification issue in bug 166108. --- ## 2. The two associations also produce different application icons There is another visible difference. When `.odt` uses: ```text LibreOffice.WriterDocument.1 ``` Windows shows a white/gray LibreOffice icon: * in Windows Settings → Default apps * as the small application overlay in the lower-right corner of `.odt` thumbnails When `.odt` is associated directly with `swriter.exe`, Windows shows the normal blue Writer icon instead. I extracted the icons from `soffice.bin`: ```text soffice.bin,0 → white/gray LibreOffice icon soffice.bin,1 → blue Writer icon ``` However, the ProgID itself is correctly registered with the blue icon: ```text HKCR\LibreOffice.WriterDocument.1\DefaultIcon = C:\Program Files\LibreOffice\program\soffice.bin,1 ``` The same `DefaultIcon` is also used by several other Writer-supported ProgIDs: ```text LibreOffice.Doc LibreOffice.Docx LibreOffice.602 LibreOffice.WriterDocument.1 ``` All four have: ```text DefaultIcon = C:\Program Files\LibreOffice\program\soffice.bin,1 AppUserModelID = TheDocumentFoundation.LibreOffice.Writer ``` But their registration differs: ```text LibreOffice.WriterDocument.1 CLSID: {F616B81F-7BB8-4F22-B8A5-47428D59F8AD} open command: "C:\Program Files\LibreOffice\program\soffice.exe" -o "%1" LibreOffice.Doc LibreOffice.Docx LibreOffice.602 no CLSID open command: "C:\Program Files\LibreOffice\program\swriter.exe" -o "%1" ``` The CLSID used by `LibreOffice.WriterDocument.1` has: ```text HKCR\CLSID\{F616B81F-7BB8-4F22-B8A5-47428D59F8AD}\DefaultIcon = C:\Program Files\LibreOffice\program\soffice.bin,0 ``` LibreOffice also registers its application-level icon as: ```text HKLM\SOFTWARE\The Document Foundation\LibreOffice\26.2\Capabilities ApplicationIcon = C:\Program Files\LibreOffice\program\soffice.bin,0 ``` So LibreOffice explicitly registers: ```text file-type icon: soffice.bin,1 → blue Writer icon application-level icon: soffice.bin,0 → white/gray LibreOffice icon ``` --- ## 3. Windows association APIs confirm that these are treated separately I also queried the association through `AssocQueryString`. For `.odt` with `LibreOffice.WriterDocument.1` as the effective ProgID, Windows reports: ```text ProgID: LibreOffice.WriterDocument.1 ASSOCSTR_DEFAULTICON: C:\Program Files\LibreOffice\program\soffice.bin,1 ASSOCSTR_APPICONREFERENCE: C:\Program Files\LibreOffice\program\soffice.exe ``` So Windows itself distinguishes the file-type icon from the associated application/icon reference. Microsoft also documents that if a thumbnail ProgID has no explicit `TypeOverlay`, Windows uses the default icon of the associated application as the thumbnail overlay. This is consistent with the white/gray icon appearing in the lower-right corner of `.odt` thumbnails even though: ```text LibreOffice.WriterDocument.1\DefaultIcon ``` correctly points to the blue Writer icon. --- ## 4. Comparison with other Writer formats For example, the effective associations on the same machine include: ```text .602 → LibreOffice.602 .doc → LibreOffice.Doc .docx → LibreOffice.Docx .odt → LibreOffice.WriterDocument.1 ``` The first three use `swriter.exe` in their open command, while `LibreOffice.WriterDocument.1` uses `soffice.exe`. This means LibreOffice currently has two different registration patterns for formats handled by Writer. --- ## Conclusions I believe there are two closely related problems here: ### Default-application detection `CheckFileExtRegistration()` treats only a ProgID matching: ```text LibreOffice.WriterDocument.1 ``` as valid. It should probably also recognize an effective association such as: ```text Applications\swriter.exe ``` as a valid LibreOffice Writer default, since Windows can legitimately create that association when the user explicitly selects LibreOffice Writer. ### Application icon / association registration `LibreOffice.WriterDocument.1` is registered differently from `LibreOffice.Doc`, `LibreOffice.Docx`, and other Writer formats: ```text WriterDocument.1 → soffice.exe Doc/Docx/etc. → swriter.exe ``` and Windows consequently exposes the generic white/gray LibreOffice application icon in places where the application icon is used, despite the ProgID's `DefaultIcon` correctly being the blue Writer icon. This appears to explain the behavior reported in bug 164862 as well. Both behaviors are reproducible on my current Windows 11 installation, so I am reopening the issue with the additional diagnostic information above. --- Disclosure: This investigation and issue report were prepared with assistance from **GPT-5.6 Sol by OpenAI**, which helped reproduce and analyze the issue, trace the relevant Windows and LibreOffice file-association and icon-resolution behavior, validate findings against APIs, registry entries, and source code, and draft this report from the collected evidence. -- You are receiving this mail because: You are the assignee for the bug.
