Can not confirm.

Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded


Could be something new with the Win11 (24H2) release build you're on.

This loss of file association (e.g. scalc.exe not associated with .ods ODF spreadsheet, and soffice.exe instead) should not happen, but we have seen past instances on Windows os/DE when MS Office product install has corrupted the registration of the soffice.bin associated .exe wrapper programs.

Use the os/DE file association manager, LibreOffice provides a launcher from its Tools -> Options -> General 'Windows Default Apps' button.

Find the LibreOffice listed in the dialog, and use its 'Manage' button.

You'll see the MS API provided handling of "File type and protocol associations" as currently registered on your system.

If you like you could try to fully uninstall LibreOffice, clean the windows registry of any LibreOffice associations and rename or delete any of the LibreOffice user profiles. And then reinstall clean from the MSI package.

Let us know if after the clean install you still are missing file associations in the either the Win11 "File Explorer" and in the Win11: Settings ->  Default Apps -> Set defaults by app  reviewing the LibreOffice "File type and Protocol associations".

(In reply to V Stuart Foote from comment #1)
> Can not confirm.
> 
> Version: 24.8.4.2 (X86_64) / LibreOffice Community
> Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
> CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render:
> Skia/Raster; VCL: win
> Locale: en-US (en_US); UI: en-US
> Calc: CL threaded
> 
> 
> Could be something new with the Win11 (24H2) release build you're on.

I don't know. It's the current release, and has been since the first day of last October.  It's been the current dev build for nearly a year.

> This loss of file association (e.g. scalc.exe not associated with .ods ODF
> spreadsheet, and soffice.exe instead) should not happen, but we have seen
> past instances on Windows os/DE when MS Office product install has corrupted
> the registration of the soffice.bin associated .exe wrapper programs.

No MS Office products are installed except OneNote, which came pre-installed with Windows 11.

What does soffice.bin have to do with soffice.exe being registered as the executable for every action for most LibreOffice file types?

> Use the os/DE file association manager, LibreOffice provides a launcher from
> its Tools -> Options -> General 'Windows Default Apps' button.
> 
> Find the LibreOffice listed in the dialog, and use its 'Manage' button.
> 
> You'll see the MS API provided handling of "File type and protocol
> associations" as currently registered on your system.

Unfortunately, that won't help. That will show LibreOffice as the file type and "OpenDocument Spreadsheet" under it. The reason is because soffice.exe is specified in the Windows registry for each action for the file type (hence that UI shows "LibreOffice" instead of "LibreOffice Calc", as it should). The fact that it states "OpenDocument Spreadsheet" is meaningless because that UI just shows the value of the FriendlyTypeName string within the corresponding registry key.

> If you like you could try to fully uninstall LibreOffice, clean the windows
> registry of any LibreOffice associations and rename or delete any of the
> LibreOffice user profiles. And then reinstall clean from the MSI package.
> 
> Let us know if after the clean install you still are missing file
> associations in the either the Win11 "File Explorer" and in the Win11:
> Settings ->  Default Apps -> Set defaults by app  reviewing the LibreOffice
> "File type and Protocol associations".

Thank you for the offer, but no, I would not like.  I can fix the problem manually much faster by simply editing the registry.  I spent my time reporting this bug so it can be fixed for all and to improve the quality of LibreOffice, not as a self-serving act. I do appreciate your well-intentioned instructions.

I think it will be best to improve LibreOffice in three (3) specific areas:

1. During all LibreOffice installs and upgrades, to set the file type associations correctly (when the user selects the corresponding options).  Given that a LibreOffice upgrade was just performed, the LibreOffice installer should have fixed this problem (whether LibreOffice caused it, or something else caused it).  But the LibreOffice installer failed to correctly set file type associations.

2. In LibreOffice, when the user selects "Tools > Options > General > Perform check for default file associations on start-up", problems like this need to be fixed.  Currently, LibreOffice fails to do so.

3. For the option mentioned in #2, the UI needs to be clarified to specify which "start-up" those words apply. System start-up? User login? LibreOffice start-up? Adding a single word before "start-up" will significantly improve the UX in this area.

I am not familiar with The Document Foundation's protocol for setting the status field for bug reports.  Thus, I will not touch it and will leave it as "NEEDINFO".  Please set it to what you determine is appropriate.  If you like, you can let me know if I was responsible for changing it when posting this reply, and next time, I will do so.

Most definitely not a bug, but the result of "fixing the problem manually much faster by simply editing the registry". Associating with soffice.exe by the installer is the correct thing to do; and the icons are ser there explicitly. E.g., the current LibreOffice_25.2.0.3_Win_x86-64.msi sets these registry entries for ODS (among others):

HKEY_CLASSES_ROOT\.ods
  (Default) = LibreOffice.CalcDocument.1

Computer\HKEY_CLASSES_ROOT\LibreOffice.CalcDocument.1\DefaultIcon
  (Default) = C:\Program Files\LibreOffice\program\soffice.bin,3

... which explicitly tells which icon from which binary to take, irrespective of the binary and its *default* icon defined in the commands (which would only be active in the absence of the explicit icon assignment).

Note that LibreOffice installer associates its file types (ODS, ODT, etc.) unconditionally, so it doesn't matter which *additional* associations you check in the installer (for MS Office file types).

(In reply to Mike Kaganski from comment #3)
> Most definitely not a bug, but the result of "fixing the problem manually
> much faster by simply editing the registry".

You conclusion is completely incorrect.  I mentioned that I *can* manually fix the problem by manually editing the registry, not that I did.  I'm not sure why you chose to ignore that critical word and omit it when quoting me.  Please do not misquote me, it is disingenuous and scientifically inappropriate.  An apology is warranted.

Your error led you to a completely false conclusion.  Given that I haven't touched the registry (nor did I state that I did), your conclusion is patently false and nonsensical.

> Associating with soffice.exe by
> the installer is the correct thing to do; and the icons are ser there
> explicitly. E.g., the current LibreOffice_25.2.0.3_Win_x86-64.msi sets these
> registry entries for ODS (among others):
> 
> HKEY_CLASSES_ROOT\.ods
>   (Default) = LibreOffice.CalcDocument.1
> 
> Computer\HKEY_CLASSES_ROOT\LibreOffice.CalcDocument.1\DefaultIcon
>   (Default) = C:\Program Files\LibreOffice\program\soffice.bin,3
> 
> ... which explicitly tells which icon from which binary to take,
> irrespective of the binary and its *default* icon defined in the commands
> (which would only be active in the absence of the explicit icon assignment).

That registry value is *not* set, and thus the LibreOffice installer is not functioning correctly.  Neither is "Tools > Options > General > Perform check for default file associations on start-up", which appears to be designed to resolve such issues.

> Note that LibreOffice installer associates its file types (ODS, ODT, etc.)
> unconditionally, so it doesn't matter which *additional* associations you
> check in the installer (for MS Office file types).

Thank you for that information.  It will hopefully reduce the chance of someone in this thread later claiming "you didn't click the correct options when installing/updating LibreOffice".  At the least, if such a claim arises, we can now point them to your words that the installer is supposed to unconditionally associate these file types.

(In reply to librelibre from comment #4)
> You conclusion is completely incorrect.  I mentioned that I *can* manually
> fix the problem by manually editing the registry, not that I did.  I'm not
> sure why you chose to ignore that critical word and omit it when quoting me.
> Please do not misquote me, it is disingenuous and scientifically
> inappropriate.  An apology is warranted.
> 
> Your error led you to a completely false conclusion.  Given that I haven't
> touched the registry (nor did I state that I did), your conclusion is
> patently false and nonsensical.

1. You are wrong when requiring me to do the quoting differently - you only would be correct if the context wasn't readily available right here. It is a single thread, not a different scientific paper, where finding the source of the quote would require a separate research.

2. I specifically designed my phrase to make it clear what I strongly suspect to be the real cause. It worked as intended, you understood it correctly. In practice, people who tend to edit registry, use different registry cleaners, etc., often break the registry structure; and the problem may not be immediate edit of the *keys in question* - sometimes a previous such edit / cleanup somewhere else could break enough to disallow correct setting of the data here. I still am not convinced that it wasn't your (previous) registry edits that caused this.

3. Given how boldly you claimed your idea of the "actual cause" of the problem ("The reason is because soffice.exe is specified in the Windows registry for each action for the file type" in comment 2 - I admit that in comment 0, you used the "perhaps", but not later), why do you require others to state their assumptions less firmly?

Now that "apology" is over, I hope that you will abstain from emotions, and focus on finding the facts. That's my goal, even when I have some reasons to suspect something, I still like to learn the problem, and you could notice that I didn't close the bug, which I would definitely do, if I was 100% sure.

> That registry value is *not* set, and thus the LibreOffice installer is not
> functioning correctly.

Please do uninstall LibreOffice, then install it again, but this time, enable logging [1]. Attach the log here.

[1] https://wiki.documentfoundation.org/Faq/General/General_Installation_Issues_(Windows)#Create_an_installation_log

(In reply to librelibre from comment #4)

> 
> That registry value is *not* set, and thus the LibreOffice installer is not
> functioning correctly.  Neither is "Tools > Options > General > Perform
> check for default file associations on start-up", which appears to be
> designed to resolve such issues.
> 

But they are, and I do see exactly those registry entries. As laid down by LibreOffice 24.8.3 (with subsequent MAR style updating)  on a Win10 (22H2 19045 build). So it has worked as expected and the correct module specific icons are associated in the WDM File Explorer in my instance.

So, Mike is right and needinfo to you is that we would need a verbose install log with debug (/l*vx) done during a clean install on your Win11 instance to do be able to do anything more with.

Thanks for opening the BZ issue and making the efforts meaningful.

(In reply to V Stuart Foote from comment #6)

In fact, I suspect that the log will be OK, and will show the normal registry entries written. And that likely, "That registry value is *not* set" is fact refers to *only one* of the two keys that I mentioned: the "HKEY_CLASSES_ROOT\.ods / (Default)". And the real problem is that there is an override in HKCU for the value *correctly existing* in HKLM.

Some background:

1. HKCR is not a normal registry hive, but a blend of two keys:

  * HKEY_LOCAL_MACHINE\SOFTWARE\Classes
  * HKEY_CURRENT_USER\Software\Classes

and the entries in HKEY_CURRENT_USER take precedence. This allows a user to override the system-level associations; and that means, that once there is the user-level override, the system-level modifications will be ineffective.

This is what I suspect to happen here. Looking at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.ods, I expect to see that the installer (doing the machine-level installation) correctly updates the (Default) value to "LibreOffice.CalcDocument.1"; but looking at HKEY_CURRENT_USER\Software\Classes, we will find a ".ods" entry there, with an own (Default) having some other value, which is effective for the user.

And that is not a bug - it's how the system offers flexibility to its users, and users are free to change that - but then there's nothing we can do. It's, as I said, some registry change by the user (or by some of their actions). LibreOffice installer doesn't (and can't) make any changes to the user-level registry.

Indeed, that's, again, a suspicion.

> 1. You are wrong when requiring me to do the quoting differently - you only would be correct if the context wasn't readily available right here. It is a single thread, not a different scientific paper, where finding the source of the quote would require a separate research.

You literally changed the meaning of what I said when you misquoted me.  The fact that you won't take responsibility for your inappropriate conduct or even offer a simple apology tells us all much about you and your lack of integrity.

> 2. I specifically designed my phrase to make it clear what I strongly
> suspect to be the real cause. It worked as intended, you understood it
> correctly. In practice, people who tend to edit registry, use different
> registry cleaners, etc., often break the registry structure; and the problem
> may not be immediate edit of the *keys in question* - sometimes a previous
> such edit / cleanup somewhere else could break enough to disallow correct
> setting of the data here. I still am not convinced that it wasn't your
> (previous) registry edits that caused this.

You keep barking up the wrong tree.  What you "strongly suspect" is nonsensical.  I never touched anything in the registry.  I'm skilled enough to do so without breaking anything, but I didn't make even a single change (nor did I state I did).  You also for some odd reason mentioned registry cleaners.  I don't use one, and never mentioned that I did.

> 3. Given how boldly you claimed your idea of the "actual cause" of the problem ("The reason is because soffice.exe is specified in the Windows registry for each action for the file type" in comment 2 - I admit that in comment 0, you used the "perhaps", but not later), why do you require others to state their assumptions less firmly?

The reason I know that's the cause is because that's the source from where Windows is obtaining the pointer to the icons.  The rest of your comment I will ignore as I'm not going to waste my time on your pathetic attempt to provoke.

(In reply to librelibre from comment #8)

Great, no sense in railing against Mike, he is the primary dev maintainer of the Windows packaging, not some shill and does not deserve your abuse. He's laid out reasonable explanation of what could be your situation, but beyond that onus is on you to work with your installation.

Please let us know what you do to resolve your issue. But I suspect Mike has the right sense of things, and that your HKCU differs from HKLM.

Two diagnostic paths I'd suggest:
1.) check the associated icon against a different local user (create a new one if needed) so it has a clean default profile in registry.
2.) as suggested earlier, completely remove LibreOffice and clean any residual from the Windows registry and then perform a clean installation allowing your user profile to build fresh. Capture a verbose installation log in the process.

If doing either you see full slate of what we would agree are normal icon associated in WDM and File Explorer, that would confirm the issue is with your HKCU. But if the issues continue, we'd need to look deeper into your installation.

NEEDINFO remains to you.