Created attachment 55133 [details]
Graphic depiction of what the FAM settings could look like
I am reproducing this bug from the old Openoffice bug system here, in the hopes that the Libreoffice devs will take a kinder view to it's implementation...
For historical purposes, the original bug was 77257:
Since that enhancement request was initiated, Libreoffice has gained support for the new xml office formats, so I'll take this opportunity to polish the screenshots for this request to take these into account.
I am attaching an updated screenshot depicting what this new FAM *could* look like (not necessarily what I think it *should* look like).
I know that there have been a few discussions about this, and that some people
have strong feelings that this is something that LibO should not do, but I want
to make my *strong* argument in favor it, so I would appreciate it if you would
take the time to read this in its entirety.
I am taking the time to create this Issue/Enhancement Request after being
bitten by this problem *again*. It has happened to me at least 5 or 6 times in the years I've been using OOo/LibO, and, although it doesn't happen very often, when it does, the ony way I have found to fix it is to reinstall *Windows* (no amount of uninstalling/reinstalling OOo/LibO has ever fixed this problkem for me), and, in my opinion, this is just not acceptable.
Recently I again had a problem where OOo/LibO lost its file associations - for its *own* file types, not MSO file types - and nothing I did was able to repair
them. A reinstall/repair of windows, does, however, every time.
First - the usual recommended method of 'right-click, open with...' is totally
unusable for me anyway, because it will not work for the Template file
associations - when templates are re-associated this way, from that point on,
OOo will not treat them as it should treat templates (copy contents of template
into new blank document, initiate prompt for input fields, etc), it just opens them, as if I had right-click>opened them.
It goes without saying that this functionality should only be available when the current user has the required Admin privileges.
All this functionality would have to do is:
1. Reset the file associations for all LibO (including the deprecated Openoffice.org 1.x) file types - *including templates* - so that they work properly with LibO.
(since OOo currently is capable of properly associating its own files upon
installation, it should be trivial to add a button somewhere in the Preferences
(I added it to the 'General' prefs in my attached screenshot), but it could even be on its own) that would simply re-associate all of the native LibO/OOo file types with LibO)
2. If the user elects *not* to allow LibOo take over the file associations for
Microsoft Office files at install time, provide a button that takes them over (*but first* records their current settings as per #3 below) - just as if the user had elected to let LibO take them over at install time, if the user later decides they like LibO enough to do so. As with the LibO file types, these choices should include the associated template files.
3. If the user elects *to allow* LibO to take over the file associations for Microsoft Office files at install time (or does so per #2), again, record the *current* file associations *before* changing them, so that the user can easily revert the changes if desired.
4. Provide a simple interface (see attached screenshot for an example of how
simple it could be) that allows the user to do #1 anytime it may become necessary, as well as an easy way to switch Microsoft Office file associations back and forth (between being associated with LibO, and what they were before/when LibO was installed) or repair them. The buttons label text should change depending on what actions would be taken (ie, 'Repair', 'Change', 'Revert', etc).
5. The File Associations Selections choices available at install time should also be expanded from 3 (.doc, .xls and .ppt) to 6 (.doc, .docx, .xls, .xlsx, and .ppt and .pptx), so that you could choose to associate only the .doc/xls/ppt file types, but NOT the .docx, .xlsx and .pptx file types if desired.
6. What is selected by default should depend on whether or not Microsoft Office is currently installed - if it is, default to NONE selected (assuming it is a version capable of working with the new XML versions, otherwise default to selecting only the ones supported by that version of Microsoft Office), if it isn't, default to ALL selected (even if .doc is already associated with Wordpad, it should still be selected by default, currently, it isn't).
Well, that's it, thanks for listening...
I have submitted this along with four other bugs to the mailing list because they are all very similar. I may create one "super bug" and close this one as a dupe because it seems like the underlying issue comes down to "defaults" & "changing file associations", I really like this mock up and I have submitted it for consideration by the developers.
There are few methods to provide a proper file associations for the Windows version of Libreoffice
1. During the command-line installation, which is convenient for mass-scale deployment
2. During the GUI installation, selecting file associations works for LibreOffice, but doesn't work for LOdev - should a new bug be filed or this can be handled in the existing bugs, such as Bug 60714?
3. Modifying the GUI installation, selecting file associations works for LibreOffice 220.127.116.11 and 18.104.22.168, but doesn't work for LOdev - related to Bug 60714 - changing file associations from the change option of add/remove programs doesn't work - so this bug should relate to LOdev only
4. Using Windows 7 Default Programs option in Control Panel is possible for LibreOffice 22.214.171.124 and 126.96.36.199 because they are registered, but it's not possible for LOdev because it's not. - related to Bug 43519 - Cannot set default file associations - I don't have Vista, but it should be same as 7. I think this bug should relate to LOdev only.
5. From within LibreOffice - not possible, and requested in Bug 44462 - Provide a proper 'File Association Manager' for the Windows version of LibreOffice.
LibreOffice is found in HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RegisteredApplications while LOdev is not.
(In reply to comment #2)
Not exactly correct. Yes, when working with the LODev builds, by default the .msi installer package does not write into the Windows registry.
For the Windows RC and Final release builds that is changed with a single toggle of the WRITE_REGSITRY value from "0" to "1".
When working with LODev builds, running the installation from a command prompt and setting WRITE_REGISTRY=1 will fully enable recording of GUI options into the Windows registry.
msiexec.exe /i libreoffice-4-0~2013-03-02_00.38.08_LibO-Dev_188.8.131.52_Win_x86.msi WRITE_REGISTRY=1
LOdev is recorded into HKLM > SOFTWARE > RegisteredApplications, and File Associations are made into HKLM > SOFTWARE > Classes
LOdev applications are available to associate as default types, which per user get modified in HKCU > SOFTWARE > Classes
Problems seem to arise with stale HKCU settings, which take precedence over HKLM settings. Or the clearing of HKCU settings, which lead to claims of "hijacking" associations.
It is Windows specific behavior that probably merits some development effort to enhance the installer and possibly as suggested integrate a more effective "File Association Manager" for LibreOffice associated file types.
adding to but 41884
*** Bug 63109 has been marked as a duplicate of this bug. ***
Thanks very much for picking up on this.
It appears one thing has changed since I opened this Feature Request, is that using the right-click>open with method does now apparently properly fix associations with the normal version of a document type (ie, .odt or .doc) also fixes the remplate version (ie, .ott or .dot) so they work as templates are expected to work.
Also, I'd like to expand a little on the concept...
First is the creation of the 'restore point' for the associations.
This means that the installer (and the FAM itself) should always 'record' the current settings of the associations before changing them. I'd even suggest expanding this to having two different restore points: 'original' (this is the state they were in prior to the very first time Libreoffice changes them, whether this is at install time, or done manually via the FAM sometime thereafter), and then a 'previous' state, that would only be available after subsequent changes are made after the 'original' state was created.
Second, is the ability to check and/or repair permissions on the registry entries that control the file associations the FAM will be managing.
This is actually one of the things that I ran into myself during one of the first times I ran into a problem with the file associations. The permissions had somehow gotten messed up. I was able to fix/reset them manually when logged on with an admin account, so if I can do it manually, then Libreoffice should be able to do it automatically (again, as long as the user is logged on with a user account that has local admin privileges).
Thanks again Joel...
This should be expanded to linux as well. The new version of Apache OOo overwrites all of the existing LO file associations. Right clicking in the file manager (Nautilus/Nemo etc) works for basic file manager associations, however that does not resolve the mime associations for mail & browser clients (SeaMonkey, Firefox, Chromium etc) & other non-file manager applications.
(This is an automated message.)
LibreOffice development currently prioritizes bugs with the so called MAB (most annoying bugs) -- as this bug has not run through that process (including writing a short rationale for this bug being a candidate and other who are watching the tracker bug silently approving that rationale etc.) its priority is set to high. Note this is effectively no change in the urgency assigned to this bug, as we are currently not making a difference between high and highest and severity is untouched.
You can find out more about MABs and how the process works by contacting libreoffice qa on irc:
The QA wiki page also gives you hints on how to get in contact with the team (if IRC fails you, your next best choice is the mailing list):
I suppose that for Windows, using its own "Default Programs" is the proper way of fixing this. So, when bug 104793 is resolved, this one will be resolved, too.
Not sure about other OSes, as mentioned in comment 7. So, I don't mark these bugs as dupes. However, I don't believe that LO should do OS (DM) integration itself. Rather, for each OS we should have its own proper method, like e.g. installer for Windows does. LibreOffice application itself should stay registration-agnostic.
Virtually copy/pasting my comment in the other bug here...
I have to disagree that resolving bug 104793 should automatically resolve this one, because - well, because resolving it does *not* resolve this one.
However, bug 104793 begs a question...
Is there a way to make these changes programatically in Windows 10, 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 this bug 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 this 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.
Thanks for listening.
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.
> 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.
Right... So instead of solving the problem for the most commonly used files you believe that is is easier to instruct users to reinstall LibreOffice every time the associations are broken???
TBH I would rather have an option to select which files are associated with LibreOffice instead of the installer using a black box approach...
> 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.
Again, right... And in case you are unaware, Microsoft resets file associations that are not associated to the program of their liking on every other Windows 10 update. I have had to associate JPG (not exactly a MS file format) to the program I prefer instead of the MS defined APP several times now on a 6 months old Windows 10 laptop...
Created attachment 129854 [details]
Screenshot of Irfanview's file association dialog
Here is how Irfanview (a Windows freeware image viewer) handles the file association problem.
(In reply to Pedro from comment #12)
> So instead of solving the problem for the most commonly used files
> you believe that is is easier to instruct users to reinstall LibreOffice
> every time the associations are broken???
:) Which of the comment 11 made you believe so? My words meant that we register all *supported* formats - and *some* most-often-used - while installing; then we use OS feature to set the program default handler of supported files that user wants, without reinstalling. BTW, registration of *supported formats* is never reset, even by MS - only registration of default handler does :)
> And in case you are unaware, Microsoft resets file
> associations that are not associated to the program of their liking on every
> other Windows 10 update. I have had to associate JPG (not exactly a MS file
> format) to the program I prefer instead of the MS defined APP several times
> now on a 6 months old Windows 10 laptop...
So, how's that relevant here? Or do you think that doing something inside LO would prevent this from happening? :) It will continue to be reset each time OS wants that; it's only MS that can fix its bugs regardless of where the setting originated that broke with next OS update.
(In reply to Pedro from comment #13)
> Here is how Irfanview (a Windows freeware image viewer) handles the file
> association problem.
Btw: IrfanView is a *Windows* program. LibreOffice is *cross-platform* program. It may be run on MacOS/Linux/Android/*BSD/...
(In reply to Mike Kaganski from comment #14)
> > And in case you are unaware, Microsoft resets file
> > associations that are not associated to the program of their liking on every
> > other Windows 10 update. I have had to associate JPG (not exactly a MS file
> > format) to the program I prefer instead of the MS defined APP several times
> > now on a 6 months old Windows 10 laptop...
> So, how's that relevant here? Or do you think that doing something inside LO
> would prevent this from happening? :) It will continue to be reset each time
> OS wants that; it's only MS that can fix its bugs regardless of where the
> setting originated that broke with next OS update.
This is not a MS bug. It's a deliberate feature ;) MS makes money by selling MS Office.
If LibreOffice wants to make it easier for it's users to keep using LibreOffice then it needs to go halfway and create user friendly solutions. Alternatively it can go the NOTOURBUG route and loose them.
>Btw: IrfanView is a *Windows* program. LibreOffice is *cross-platform* program. >It may be run on MacOS/Linux/Android/*BSD/...
But you do know that some features are adapted according to the OS, right?
If you believe this feature can not be added, just ignore it. Maybe someone else might like to give it a go ;)
(In reply to Pedro from comment #16)
> If you believe this feature can not be added, just ignore it. Maybe someone
> else might like to give it a go ;)
I believe that this feature *should not* be added, that's why I post my reasons here, so that someone who might like to give it a go (or reviewers) could weigh both PoVs.