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.
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.
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.
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.
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
Andras, Christian - any ideas ? some signing problem on Windows ?
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.
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.
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.
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.
Fridrich - you were looking for Windows specific regressions to look into ? :-) this looks like a nice one ...
(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.
I could not reproduce the bug, when I took embedserv sources from 4.0 and build 4.1 with it.
I bisected it, and it turned out that Noel Grandin's commit broke it. http://cgit.freedesktop.org/libreoffice/core/commit/embedserv?id=b248624126c271c88381d3dad6e04fc954f65779
(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.
Thanks, it works with this fix, indeed.
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.
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.
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).
*** Bug 75558 has been marked as a duplicate of this bug. ***
(In reply to comment #18) > Also, Bug 66232 indicates that the problem remains in 4.1.5 I meant Bug 75558
(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?
(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.
thanks Mike for feedback. I move this to mab4.2 list.
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
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.
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.
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?
(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.
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.
Submitted patch to gerrit - https://gerrit.libreoffice.org/15607
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.
Bug is confirmed for LO v.4.4.3.2-RC2 (RC for actual fresh LO).
I checked the fix from Mike Kaganski, and it worked. Well done, thanks. Backport to 4-4 proposed: https://gerrit.libreoffice.org/15618
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!
Bug in actual Still version is heavy affecting all migration projects to LO. Please consider if backport the solution to v. 4.3.
(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.
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
It was too late for 4.4.3. I'm positive that it will be part of 4.4.4.
Great! It's allready a 4.4.4 build to test?
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.
(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/