Bug Hunting Session
Bug 39791 - FILEASSOC LibreOffice installation steals .doc association from MS Office by default
Summary: FILEASSOC LibreOffice installation steals .doc association from MS Office by ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: x86 (IA32) Windows (All)
: high major
Assignee: Andras Timar
URL:
Whiteboard: target:3.7.0
Keywords:
: 42473 47483 (view as bug list)
Depends on:
Blocks: Win-Installer-MAB
  Show dependency treegraph
 
Reported: 2011-08-03 01:57 UTC by Adrian Wilkins
Modified: 2013-03-05 09:44 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
MSI Logs, password is 4321 (1.44 MB, application/save-as)
2012-05-03 01:51 UTC, Michail Pappas
Details
Test scenarios examined under different Office installations (11.27 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-05-04 03:31 UTC, Michail Pappas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Wilkins 2011-08-03 01:57:11 UTC
After a default installation of LibreOffice 3.4.2, the .doc file extension is associated with LibreOffice Writer, even if Microsoft Office is installed already.

While I'm sure this is fine on a machine without Office available, on a machine with Office installed this is going to cause some complaints. I note that the installer doesn't take the .xls or .ppt extensions, let alone the .docx extension.

Suggested behaviour would be to only take the primary association where MS Office is not installed. Windows supports secondary associations in the "Open With" explorer context menu, adding an entry to this would be the best option where Office is already installed - this appears to be the behaviour for the other applications in the LibreOffice suite.
Comment 1 fabio figueiredo 2011-09-01 06:55:28 UTC
OS: Windows XP SP3 x32
MS Office:  2010 home & b
LibreOffice :  3.3.3 and 3.4.2

remove previous installation of openoffice 

installation : unset box LibreOffice as default to open .doc files.

LibreOffice or Openffice unset the file association for all documents ...

so i have to go and set the association for each types of file. doc docx xls xlsx pps ppsx etc...
Comment 2 Björn Michaelsen 2011-12-23 12:24:49 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 3 Rich Painter 2012-01-03 22:10:33 UTC
LibO 3.4.4
Windows XP Pro SP3 32bit
MS Office 2000 and 2003

I had various Microsoft Office programs installed in addition to OpenOffice. OpenOffice was NOT configured to be the default for any file types.

I uninstalled OpenOffice and installed LibO 3.4.4.

This set the default association for .doc and .oxt to LibreOffice and nothing else. The remaining files types are still pointing to Microsoft Office.

I don't recall being asked by the LibO installer to do *any* file association nor ask if I wanted it to be my default office document software.

There should be an installer question as to how to handle this.

regards
rich
Comment 4 sasha.libreoffice 2012-03-01 05:32:54 UTC
Thanks for bugreport
Please, verify: in last version of LibreOffice problem remains?
Comment 5 Michail Pappas 2012-04-30 01:56:27 UTC
Issue seems to be resolved with 3.5.2. I tried installing via msiexec /qn. MS Office 2000 was installed. Associations were not stolen.
Comment 6 Michail Pappas 2012-05-03 01:51:56 UTC
Created attachment 60951 [details]
MSI Logs, password is 4321

Seems I spoke too early: I made an administrative install of 3.5.2 and installed from there, using a transform file. Results:

1) On computers joined to my active directory domain: When installing either via:
 msiexec /i <libo.msi> TRANSFORMS=MyLanguageSelectionTransform /qn 

... or via group policy with the same settings, .doc files still get associated with LibO! This happens only for .doc, and not for .xls/.ppt files...

2) On single computers, when installing via the SAME msiexec command line as above, applied to the same administrative image, associations remain correct!!!

Puzzled, puzzled. I am attaching a log file from case (2), as case2log.txt. I am also attaching the MSI log from running a silent install on a domain computer, with no transforms applied, that is:
msiexec /i <libo.msi> /lvoicewarmupx c:\case3log.txt /qn

The .7z file is encrypted with password 4321 (don't ask why, just had to do it...).
Comment 7 Andras Timar 2012-05-03 02:16:09 UTC
If I understand correctly, you do not want to associate MS file formats to LibreOffice at all. Have you tried to use REGISTER_NO_MSO_TYPES property, as described in the README? Like:

msiexec /i <libo.msi> TRANSFORMS=MyLanguageSelectionTransform REGISTER_NO_MSO_TYPES=1 /qn 

Does this work for you?
Comment 8 Rainer Bielefeld Retired 2012-05-03 02:21:55 UTC
*** Bug 42473 has been marked as a duplicate of this bug. ***
Comment 9 Michail Pappas 2012-05-03 04:19:52 UTC
(In reply to comment #7)
> If I understand correctly, you do not want to associate MS file formats to
> LibreOffice at all. Have you tried to use REGISTER_NO_MSO_TYPES property, as
> described in the README? Like:
> 
> msiexec /i <libo.msi> TRANSFORMS=MyLanguageSelectionTransform
> REGISTER_NO_MSO_TYPES=1 /qn 
> 
> Does this work for you?

This command worked just fine on my domain computers. However, up to a specific LibO (or was it Oo) version, specifying REGISTER_NO_MSO_TYPES was not required at all. If I wanted to grab MS document associations, I just did a REGISTER_ALL_MSO_TYPES=1. If I didn't, I specified nothing at all. What changed?

Additionally, in the stock msi I can see that SELECT_WORD=0, as are the relevant Excel and Powerpoint MSI values.

Bottomline: what is *expected* to happen when the msi is installed as is? Associate all? Nothing? Word only? If the correct answer is the last one, then it's a feature, otherwise it's a bug as is.

Will try to throw in some logs tomorrow.
Comment 10 Andras Timar 2012-05-03 10:29:34 UTC
(In reply to comment #9)

> Bottomline: what is *expected* to happen when the msi is installed as is?
> Associate all? Nothing? Word only? 

None of above. It tries to find out if you already have those file formats associated, and tries to keep original associations by default.
Comment 11 Michail Pappas 2012-05-03 21:51:36 UTC
Th(In reply to comment #10)
> (In reply to comment #9)
> 
> > Bottomline: what is *expected* to happen when the msi is installed as is?
> > Associate all? Nothing? Word only? 
> 
> None of above. It tries to find out if you already have those file formats
> associated, and tries to keep original associations by default.

Thank you for the clarification, this might explain why in some cases .doc got associated with LibO. So, this seems like a definite bug, see comment #6 (respective log file case3log.txt).

If more info is needed from our side, please let us know.
Comment 12 Michail Pappas 2012-05-03 22:44:26 UTC
Stranger and stranger: I made another test on the same system I carried out a test with REGISTER_NO_MSO_TYPES=1 (see Comment 9), this time without setting any variable at all. Just a single msiexec /i <libo.msi> /qn. No problems at all!!!

For what it is worth, MS Office XP (2002) was installed on this system. I need to isolate this though, once and for all...
Comment 13 Michail Pappas 2012-05-04 03:31:39 UTC
Created attachment 61015 [details]
Test scenarios examined under different Office installations

After performing a number of tests, I have the feeling that this is not related to whether a system is part of a domain or not. The decisive factor seems to be the version of the currently installed MS Office. I have attached a small table that shows the tests performed. In a nutshell:

* In all cases, setting REGISTER_NO_MSO_TYPES worked fine; .doc associations were never stolen, regardless of Office version installed

* Problems were found when installing with "msiexec <libo.msi> /qn" on Office 2007, as well as all (except one) of Office 2003 installations.

I hope this "investigation" holds...
Comment 14 Timur 2012-05-07 04:34:44 UTC
While this request is logical, I find that the problem can be avoided with full control of the silent installation, as in https://wiki.documentfoundation.org/Deployment_and_Migration.
Comment 15 Joel Madero 2012-07-03 10:58:33 UTC
This is the fourth bug similar to this one that I've seen. I think for Windows users could have a headache if they do the default install and lose file association with MS products. 

Here is the solution that I personally like best but it's just one of many: https://bugs.freedesktop.org/show_bug.cgi?id=44462&list_id=89889

I'm trying to track down the other ones that I found that are similar to this one
Comment 16 Andras Timar 2012-07-03 13:28:22 UTC
I think I have found it. LibreOffice steals file types from MS Office, if WordPad.exe is also associated to that file type under OpenWithList key. I don't know what was the plan, but it looks like a bug to me.

I'll make a patch.
Comment 17 Michail Pappas 2012-07-04 21:36:56 UTC
(In reply to comment #16)
> I think I have found it. LibreOffice steals file types from MS Office, if
> WordPad.exe is also associated to that file type under OpenWithList key. I
> don't know what was the plan, but it looks like a bug to me.

Are you sure about that? My own testing was performed on the exact same system, a Windows 7 VM (see comment# 13). After this "clean" snapshot was taken, I installed Office 2000, made my tests and then reverted the clean snapshot to make sure that I started over clean. Then I installed the next Office version etc.

Bottomline: if your hypothesis is true, then in all cases I examined shouldn't I have the bug exhibited, since in all cases Wordpad is associated with the MSoff filetypes? Or, conversely, if Wordpad was not associated with these files, the bug should appear in no tests at all.

This was not the case of my findings: I had inconsistent results and the affecting factor seemed to be the Office version installed.

If you have something to test (your patched version), I'd be more than happy to check it out, since I've kept snapshots of the VMs with the different Office versions.
Comment 18 Michail Pappas 2012-09-12 06:18:50 UTC
(In reply to comment #14)
> While this request is logical, I find that the problem can be avoided with full
> control of the silent installation, as in
> https://wiki.documentfoundation.org/Deployment_and_Migration.

Update: issue persists in 3.6.1. Specifically, installing via gpo on Windows XP Pro systems with MS Office 2002 already installed, and with REGISTER_NO_MSO_TYPES set to true (REGISTER_NO_MSO_TYPES=1) *still* destroys the association with .doc: now they are set to open with wordpad. Excel file associations were not affected.
Comment 19 Michail Pappas 2012-09-12 06:38:48 UTC
(In reply to comment #18)
> Update: issue persists in 3.6.1. Specifically, installing via gpo on Windows XP
> Pro systems with MS Office 2002 already installed, and ...

One correction, program was installed alongside Office 2003. Checking comment# 13, one can see in the attachment that Office 2003 is one of the MS office environments where this bug is exhibited.
Comment 20 Not Assigned 2012-09-12 14:15:45 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e2b1a7e4e4d9bfc32aab9921c30a6e40e08b8210

fdo#39791 do not steal .doc association from MS Word



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 21 Timur 2013-02-26 09:22:16 UTC
This is still ASSIGNED. Can those affected confirm this is SOLVED?
Comment 22 Andras Timar 2013-02-26 09:32:20 UTC
I think I solved the problem described in comment 16. This bug has many comments, and they are confusing. I'm closing this one.
Comment 23 Timur 2013-03-05 09:44:39 UTC
*** Bug 47483 has been marked as a duplicate of this bug. ***