Summary: | FILEOPEN: cannot open .odt files by clicking on a hyperlink in IE | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Mike Kaganski <mikekaganski> |
Component: | Libreoffice | Assignee: | Andras Timar <timar74> |
Status: | REOPENED --- | QA Contact: | |
Severity: | critical | ||
Priority: | highest | CC: | barta, iveand, jmadero.dev, lohmaier, michael.meeks, noelgrandin, pasqual.milvaques, qubit, r.domenge, sbergman, timar74 |
Version: | 4.1.0.1 rc | Keywords: | regression |
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=65765 https://bugs.freedesktop.org/show_bug.cgi?id=75558 |
||
Whiteboard: | Confirmed:4.1.0_RC1:Windows8 NoRepro:4.0.4.2:Windows8 target:4.2.0 target:4.1.4 | ||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 75025 | ||
Attachments: | Dialogs screenshots |
Description
Mike Kaganski
2013-06-27 02:21:41 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. 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.