Windows 10's default "set default file handler" application interface does not list Libreoffice Writer as an option for doc/docx and other Microsoft Word formats. Libreoffice Writer opens the programs fine - it's just that, for some reason, Writer isn't properly registering itself in a way that ensures ui consistency.
Steps to Reproduce:
1. Install LO 5.2.3, set LO as default for all MS Office file types within the installer
2. Go to "Control Panel\Default Programs" and click Set Default Programs. Find Libreoffice 5.2, and check the .docx file association.
3. Under the "Current Default" header for .doc/.docx and similar files, the program presented should be Libreoffice Writer. Instead, it reads "Unknown Application"
As mentioned above, under the "Current Default" header for .doc/.docx and similar files, the program presented should be Libreoffice Writer. Instead, it reads "Unknown Application"
Libreoffice Writer should display as the default program for those file extensions.
User Profile Reset: Yes
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.28 Safari/537.36
Created attachment 129790 [details]
Screenshot of problem
I want to add that, even though this is most obvious in LO Writer, this quirk is replicated for multiple programs within the Libreoffice Suite.
On Windows 10 Pro 64-bit en-US with
Version: 188.8.131.52 (x64)
Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default;
Locale: en-US (en_US); Calc: group
Could be an issue in our packaging for Windows if the file association are not taking on Windows 10.
Created attachment 129810 [details]
clip from Windows 10 Set Associations dialogs with LibreOffice Writer (184.108.40.206) default
Yeah, .doc files (and .docx) are definitely opening with LO Writer. I wonder why the Windows interface still lists unknown application as the default file opener?
IMO, the bug 44462 that I add as "See Also", will be resolved for Windows if this enhancement is finished, because this will enable OS-consistent way of defining file associations.
As the OP for bug 44462, I have to disagree that resolving this bug should automatically resolve mine, because - well, because resolving this one does *not* resolve mine.
However, this bug begs a question...
Is there a way to make these changes programatically, without being dumped to the Default Programs screen?
I think the answer is yes, because I don't recall being dropped to that screen when I first installed LibO on my laptop after clean installing windows 10.
But I ask this because this is what happens when I install Firefox for someone. With Windows 7, you just clicked 'OK' on the first run to set it as default. Done. In Windows 10, after you click OK to set it as default, you're then brought to the Windows Default Programs settings page where you have to manually select Firefox and change it.
Now I'm off to open a bug for Firefox to set itself as the default without getting dropped to that screen - but I have a feeling that because Microsoft really wants users to use Edge, they may not let another web browser take over as the default without the extra hassle.
So, if there is a way to accomplish these changes without having to jump through those hoops, and it is possible to properly manage these fully from within LibO - which apparently is the case - I still think bug 44462 would be a valuable addition, simply because it puts all of the relevant file associations in one place and let's you see at a glance which one is set for LibO and which for MSO.
What I would do for my bug though is to add a single option to 'Allow Windows to control these for me', which could be made default if the devs so desired.
Of course, my being the OP for bug 44462 doesn't have anything to do with this opinion. ;)
Well, first of all, there are functions that are best done by OS/desktop manager. This one is one of them. More generally, it is not good to duplicate any OS-provided functionality in program, because doing this, the program takes responsibility to catch up with any changes in OS function; it should do that for any OS/DM it works on; it will need to fix its own bugs in this implementation etc. Now it is done by proper registration using proper method (installer technology suited for that kind of tasks and doing most of the job) - some small tweaks are only needed.
Second, doing so, we cannot stop with MSO file types only. Why? We can handle a multitude of formats, textual, spreadsheets, graphical, presentations, ... Where to stop? And by doing that, you will eventually loose the presumed ease of seeing associations of MSO files in one place.
Third, you may be unaware of this, but Windows "Default Programs" has a mode that already makes what you need: it is called "Set defaults by app". There you just choose a program (e.g. LibreOffice), and choose defaults for that program in one place. See e.g. https://www.cnet.com/how-to/how-to-set-default-programs-in-windows-10/
Lastly: it's not hammer's job to check if its owner uses it by default for hammering nails.
This is fixed in LO 220.127.116.11, which is currently in testing.
Having a similar File Association issue.Calc is not launching correctly from File Association. Noticed this after latest Windows 10 update to Version 1607 Build 14393.693 . I usually update an .xls file monthly by simply launching from Nexus File Manager using the Windows Default Programs File Association. Worked correctly before Update for Windows 10 Version 1607 for x64-based Systems (KB3211320) which installed on 1/25/2017 and the latest Libre Office update Version: 18.104.22.168 (x64).
I end up with multiple processes of Libre Office running in Task Manager as well as a Calc entry but no launch of Calc. Played with Default Programs and see some of the other issues described. It will usually launch once after a boot, but can not then re-open from file association. Usually have to kill the processes then before you can open the file even from within normal Libre Office program open from the desktop.
I tried just resetting the Profile and also uninstalled and re-installed. Definitely something going wrong with File Associations.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!