Bug 66232 - FILEOPEN: cannot open .odt files by clicking on a hyperlink in IE
Summary: FILEOPEN: cannot open .odt files by clicking on a hyperlink in IE
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.1 rc
Hardware: x86-64 (AMD64) Windows (All)
: highest critical
Assignee: Mike Kaganski
URL:
Whiteboard: target:5.0.0 target:4.4.4
Keywords: bisected, regression
: 75558 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2013-06-27 02:21 UTC by Mike Kaganski
Modified: 2015-07-10 16:44 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Dialogs screenshots (278.20 KB, application/x-zip-compressed)
2013-07-12 13:39 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2013-06-27 02:21:41 UTC
LO 4.1.0.1 on Win7x64; IE10

When clicking on a hyperlink to a .odt file and selecting Open, the file isn't opened.

If LO isn't open yet, the task manager shows that soffice.bin and soffice.exe processes are started, and soffice.exe displays activity and consumption of memory, until it reaches ~25 MB memory consumption. Then it seems to hang: no memory usage change, no CPU use. No UI is displayed. However, if in this state I try to open another document from a local drive, it is opened normally.
 
If LO is already started, it simply doesn't open the document from a web page.

In both cases, after such attempt to load a document by clicking a hyperlink, LO cannot be closed (neither by clicking the cross at top right, nor by File->Exit LO). Kill process is needed.

As a testcase, I tried some documents from Bugzilla, e.g. Attachment 81382 [details] from Bug #66141.

IIRC, neither 4.0.4 nor 3.6.x had this problem.
Comment 1 Mike Kaganski 2013-06-27 02:52:42 UTC
Correction:

LO 3.6.3.2 cannot open the links when it is not opened in advance, but it doesn't "hang"; instead, it displays the message box saying the following:

"LibreOffice 3.6

Unknown option: -Embedding

Usage: soffice [options] [documents...]
Options:
<... a long list of command line options ...>"

Clicking the OK button closes LO.

If it is already started, it opens such files normally, and no problems to close LO after that.
Comment 2 Mike Kaganski 2013-06-27 03:06:21 UTC
The behaviour of 3.6.3 differs from what happens in 4.1; besides, it seem to be fixed in Bug #57203. That's why I beleive that this is a distinct bug, and don't set version to an older version.
Comment 3 Mike Kaganski 2013-06-29 14:21:48 UTC
This only happens if the MIME type of the downloaded file is set correctly (e.g., application/vnd.oasis.opendocument.text), and no download managers are used.

IE shows two dialogs before trying to open the file: first is to choose what to do: Open, Save or Save As. Second (after choosing Open) is security warning saying that "A website wants to open web content using this program on your computer" and soffice.exe doesn't have a valid signature.

When the opening fails, three events are generated by this bug in the Application Log: Application Error 1000 (faulty application soffice.bin 4.1.0.0, faulty module emserlo.dll 4.1.0.1, exception 0xc0000005), and two Windows Error Reporting events 1001.
Comment 4 Joel Madero 2013-06-29 21:38:17 UTC
Windows 8
LibreOffice - 4.1 RC1
LibreOffice - 4.0.4.2

I can confirm the behavior on 4.1 but not on 4.0 so indeed a regression

New - confirmed
Critical - opening a document directly from web browser is common task - with IE still being the default of Windows (who knows why...) we should expect 4.1 to open the file just like it did in 4.0. Furthermore, the lock of the software makes it a bit more serious.
Highest - very common thing to want to do
Comment 5 Michael Meeks 2013-07-01 13:30:24 UTC
Andras, Christian - any ideas ? some signing problem on Windows ?
Comment 6 Andras Timar 2013-07-12 12:54:17 UTC
I tried LO 4.1.0.2 in Windows 8 (IE10) and LO 4.1.0.1 on Windows 7 (IE10). 

I reproduced the bug on Windows 8 but not on Windows 7, which is confusing, because the reported had the bug under Windows 7.

However, I did not see anything in Event Viewer's Application log. Also, I did not see any problem with signatures.

I compared the Process Monitor output of LO 4.0.4 and LO 4.1.0.2 and I see no difference, the .odt file was opened on both case. 

I suspect that the bug is somewhere in desktop/source/app, IE10 starts LO in headless state or something like that.
Comment 7 Mike Kaganski 2013-07-12 13:39:50 UTC
Created attachment 82367 [details]
Dialogs screenshots

Just some clarification:

there's no problem with signature (I suppose). I may have made slightly misleading descriptions above. Let's try to be more clear this time :)

When I open example link from Comment 0 from MS IE browser, it will naturally emit these dialogs:
1. To choose the action: Open / Save / Save As.
2. To confirm the action of the LibreOffice program installed on the computer to interact with the web page (thus breaking the IE protected mode).

They are usual dialogs, that don't have anything strange.
I only wanted to show the exact steps required to reproduce the dug. Because if you have, say, a download manager that intercepts the download and calls LO itself, then you will not see these dialogs, and will be unable to reproduce the bug. Similarly, if you try to download a file that have not MIME properly set, then IE will simply download the file and then start its associated program, instead of doing this "interaction of program and WEB page" thing, in which case you will not see these dialogs, and will be unable to reproduce the bug.

Hope this helps. Please ask if you need some additional info.
Comment 8 Andras Timar 2013-07-12 14:09:55 UTC
OK, I reproduced the bug with Windows7/IE10, too.

I compared the command lines of LibreOffice's invocations.

Windows XP - IE8 (good):
-o C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\LYH5XXZ4\bug[1].odt --writer 

Windows 7 - Firefox (good):
C:\Users\timar\AppData\Local\Temp\bug-2.odt

Windows 7/8 - IE10 (bad):
--nodefault --nologo -Embedding

The filename is not passed vie the command line, yet I see it in the Process Monitor, so it is passed by other means.
Comment 9 Andras Timar 2013-07-12 15:15:17 UTC
The --nologo --nodefault switches come from the registry, for example for .odt from HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{F616B81F-7BB8-4F22-B8A5-47428D59F8AD}\LocalServer32

This explains, why opening works even from IE10, when LibreOffice is not installed (just extracted to disk with msiexec /a, a.k.a. administrative install), because in this case nothing is written to registry.

The real question is, why did LibreOffice's behaviour change between 4.0 and 4.1. 4.0 works with the same registry settings.
Comment 10 Michael Meeks 2013-07-18 14:12:22 UTC
Fridrich - you were looking for Windows specific regressions to look into ? :-) this looks like a nice one ...
Comment 11 Robinson Tryon (qubit) 2013-11-06 09:03:44 UTC
(In reply to comment #4)
> Windows 8
> LibreOffice - 4.1 RC1
> LibreOffice - 4.0.4.2
> 
> I can confirm the behavior on 4.1 but not on 4.0 so indeed a regression

Adding Repro tags to the Whiteboard per Joel's repro notes.
Comment 12 Andras Timar 2013-11-14 12:32:04 UTC
I could not reproduce the bug, when I took embedserv sources from 4.0 and build 4.1 with it.
Comment 13 Andras Timar 2013-11-14 15:29:02 UTC
I bisected it, and it turned out that Noel Grandin's commit broke it. 
http://cgit.freedesktop.org/libreoffice/core/commit/embedserv?id=b248624126c271c88381d3dad6e04fc954f65779
Comment 14 Stephan Bergmann 2013-11-19 11:19:06 UTC
(In reply to comment #13)
> I bisected it, and it turned out that Noel Grandin's commit broke it. 
> http://cgit.freedesktop.org/libreoffice/core/commit/
> embedserv?id=b248624126c271c88381d3dad6e04fc954f65779

I assume that

> - uno::Reference<beans::XPropertySet> xPS(m_xFrame,uno::UNO_QUERY);
> - if( xPS.is() )
> - {
> - aAny = xPS->getPropertyValue(
> - OUString("LayoutManager"));
> - aAny >>= m_xLayoutManager;
> - }
> + m_xLayoutManager.set( m_xFrame->getLayoutManager(), UNO_QUERY_THROW );

is wrong there and the last line should read

> + m_xLayoutManager.set( m_xFrame->getLayoutManager(), UNO_QUERY );

instead.
Comment 15 Andras Timar 2013-11-19 11:37:20 UTC
Thanks, it works with this fix, indeed.
Comment 16 Commit Notification 2013-11-19 11:48:58 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

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

fdo#66232 fix opening files via COM server



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 17 Commit Notification 2013-11-19 14:55:51 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=53edaf552528981e54f7bc567d88421c4741ed17&h=libreoffice-4-1

fdo#66232 fix opening files via COM server


It will be available in LibreOffice 4.1.4.

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 18 Mike Kaganski 2014-03-17 02:56:58 UTC
Unfortunately, the fix doesn't work with 4.2.2.1 and IE11 under Win7x64. Also, Bug 66232 indicates that the problem remains in 4.1.5 (while it should have been fixed for 4.1.4).
Comment 19 Mike Kaganski 2014-03-17 02:57:20 UTC
*** Bug 75558 has been marked as a duplicate of this bug. ***
Comment 20 Mike Kaganski 2014-03-17 03:01:43 UTC
(In reply to comment #18)
> Also, Bug 66232 indicates that the problem remains in 4.1.5

I meant Bug 75558
Comment 21 tommy27 2014-05-03 08:32:02 UTC
(In reply to comment #18)
> Unfortunately, the fix doesn't work with 4.2.2.1 and IE11 under Win7x64.

Tested under Win7x64 using Internet Explorer 11 and Opera 12.16
I use LibO 4.2.3.3 portable version from WinPenPack which is set as default .odt opening application in my PC.

If I click on that Attachment 81382 [details] hyperlink both browser show me an "open/save" dialog and if I select "open" LibO is correctly launched and loads that file.

so it seems to me that it's fixed. what about you Mike? does a regular LibO 4.2.3.3 installation still has the bug or has it been finally fixed?
Comment 22 Mike Kaganski 2014-05-03 10:22:52 UTC
(In reply to comment #21)
> I use LibO 4.2.3.3 portable version from WinPenPack which is set as default
> .odt opening application in my PC.

That's the point. As it was noted in comment 9, the problem doesn't manifest itself in "administrative"/"portable" installations.

I do confirm that the problem is still REPRODUCIBLE with IE11 and LO 4.2.3.3 under Win7x64. Specifically: in NORMAL installation of LO, if I click the abovementioned link in IE, the dialog shows up prompting if I want to open or save the file; then if I chose "Open", it shows another dialog asking that I confirm the action by LibreOffice, and after I confirm, nothing is shown. Task manager shows that LO is started, but UI isn't displayed.
Comment 23 tommy27 2014-05-03 10:32:27 UTC
thanks Mike for feedback. I move this to mab4.2 list.
Comment 24 tommy27 2014-11-30 20:09:04 UTC
please Mike, tell if issue is still present with 4.3.x or 4.4.x
if yes, this bug has to be moved to mab4.2 list since 4.2.x is END OF LIFE
Comment 25 Mike Kaganski 2014-11-30 20:58:32 UTC
Unfortunately yes, 4.3.4.1 still has it.
Cannot say anything about 4.4 - have not yet installed it to handle MIME associations in IE.
Comment 26 DiegoM 2015-04-21 16:19:04 UTC
Confirmed bug on version 4.3.6.2 under W7+IE11.
Process launch was analized via 
wmic:root\cli>process get Name,Caption,CommandLine,ProcessId,ParentProcessId
and action between Firefox and IE was compared.

Clicking on a link in Firefox starts LibreOffice as follows:

FIREFOX
scalc.exe               "C:\Program Files (x86)\LibreOffice 4\program\scalc.exe" -o "C:\Users\DMANIA~1\AppData\Local\Temp\HBED14_OpereEdili_20141103-2.ods"
soffice.exe             "C:\Program Files (x86)\LibreOffice 4\program\scalc.exe" -o "C:\Users\DMANIA~1\AppData\Local\Temp\HBED14_OpereEdili_20141103-2.ods" --calc
soffice.bin             "C:\Program Files (x86)\LibreOffice 4\program\scalc.exe" "-o" "C:\Users\DMANIA~1\AppData\Local\Temp\HBED14_OpereEdili_20141103-2.ods" "--calc" "-env:OOO_CWD=2C:\\Users\\DMANIA~1\\AppData\\Local\\Temp"

We have evidence that Firefox downloads the file and than calls LO for opening.

Clicking on a link in IE starts LO as follows, but with UI no-interface, LO must be stopped via taskmanager:

IEXPLORER
soffice.exe             "C:\Program Files (x86)\LibreOffice 4\program\soffice.exe" --nodefault --nologo -Embedding
soffice.bin             "C:\Program Files (x86)\LibreOffice 4\program\soffice.exe" "--nodefault" "--nologo" "-Embedding" "-env:OOO_CWD=2C:\\WINDOWS\\system32"

Tha ActiveX component which should take care of this part 
"https://help.libreoffice.org/3.3/Common/ActiveX_Control_to_Display_Documents_in_Internet_Explorer"
is apparently not working anymore.

Removing the --nodefault option from registry for LO launching (example: HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{30A2652A-DDF7-45e7-ACA6-3EAB26FC8A4E}\LocalServer32) modify behaviour as follows:
Clicking on a link in IE starts LO with general UI interface which react but cannot be closed, just via taskmanager.
Comment 27 DiegoM 2015-04-29 17:06:37 UTC
NOTE!!!
In bug 75558 (now closed) same problem is reported for OpenOffice.
Operating System: Windows 7
OO Version: 4.1.5.3 release

Question: is ActiveX component common to OO and LO?
Comment 28 Mike Kaganski 2015-04-29 22:31:42 UTC
(In reply to DiegoM from comment #27)
> In bug 75558 (now closed) same problem is reported for OpenOffice.
> Operating System: Windows 7
> OO Version: 4.1.5.3 release

I'm afraid that OP of bug 75558 simply used wrong name for LO. AOO have no version 4.1.5.3.

I'll try to look into this soonish.
Comment 29 DiegoM 2015-04-30 14:18:37 UTC
Confirmed bug on LibreOffice version 4.3.7.2 under W7+IE11, with or without (*) ActiveX component installed..
Backgrading LO to 4.0.6.2 solve the issue, with or without (*) ActiveX component installed.
(*) be unshure if deinstallation really removes this ActiveX.
Comment 30 Mike Kaganski 2015-05-03 13:33:52 UTC
Submitted patch to gerrit - https://gerrit.libreoffice.org/15607
Comment 31 Commit Notification 2015-05-03 16:15:02 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#66232: Cannot open files by COM2

It will be available in 5.0.0.

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 32 DiegoM 2015-05-04 08:04:30 UTC
Bug is confirmed for LO v.4.4.3.2-RC2 (RC for actual fresh LO).
Comment 33 Andras Timar 2015-05-04 08:12:56 UTC
I checked the fix from Mike Kaganski, and it worked. Well done, thanks. Backport to 4-4 proposed: https://gerrit.libreoffice.org/15618
Comment 34 DiegoM 2015-05-04 08:38:13 UTC
Bug for me is SOLVED with Daily version master~2015-05-04_03.49.24_LibreOfficeDev_5.0.0.0.alpha1_Win_x86.

Test bed as follows:
- Win7 64 bit
- IExplorer 11
- ActiveX LO component installation was Checked
Web page used for test contains 1 link to .ODT and 3 links to .ODS:
http://www.provincia.bz.it/it/amministrazione-trasparente/attestazioni-oiv-struttura-analoga.asp

Clicking on the links opens the files from IE Browser as expected.

NOTE: File-set association must be manually configured, automatic association does not work with installer this build!
Comment 35 DiegoM 2015-05-04 08:41:44 UTC
Bug in actual Still version is heavy affecting all migration projects to LO.
Please consider if backport the solution to v. 4.3.
Comment 36 Andras Timar 2015-05-04 08:46:37 UTC
(In reply to DiegoM from comment #35)
> Bug in actual Still version is heavy affecting all migration projects to LO.
> Please consider if backport the solution to v. 4.3.

TDF does not plan more releases from the 4.3 code line. You can backport the fix yourself, and build yourself, or you can buy professional support.
Comment 37 DiegoM 2015-05-07 13:15:13 UTC
4.4.3 was released today. It is binary-equal to 4.4.3.2_RC2, where the bag is confirmed.
I had a look to  https://gerrit.libreoffice.org/15618 . Did not understand if backport to 4.4 is confirmed or not.

I would like to "press" for have this fix backported to 4.4.4, remarking the importance for the "real world" of LO users.
Tanks,
diego
Comment 38 Andras Timar 2015-05-07 13:22:18 UTC
It was too late for 4.4.3. I'm positive that it will be part of 4.4.4.
Comment 39 DiegoM 2015-05-07 13:52:03 UTC
Great! It's allready a 4.4.4 build to test?
Comment 40 Commit Notification 2015-05-07 14:02:43 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=73eb60c8f958c6e33cde897194711111e31b45c2&h=libreoffice-4-4

tdf#66232: Cannot open files by COM2

It will be available in 4.4.4.

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 41 tommy27 2015-05-10 08:48:26 UTC
(In reply to DiegoM from comment #39)
> Great! It's allready a 4.4.4 build to test?

go here and grab a 4.4.4 daily 
http://dev-builds.libreoffice.org/daily/libreoffice-4-4/