Created attachment 159302 [details] Screenshot Hi, since using 6.4.2.2 I regularly experience the following regression: Every time I start LibreOffice (the basic framework with recent file list icons; not a dedicated app) LO freezes for many seconds. When I close LibreOffice documents of any type, LO hangs for longer times and sometimes shows failure message like the ones in my screenshot attached. Some background information: These issues seem to be provoked by the fact that my recent file list contains some files which are stored on remote-smb behind VPN. LibreOffice hangs as described above in case the VPN connection has been closed meanwhile so that some files from recent file list are not accessible. I never experienced these issues with 6.3 builds. I assume there have been some modification to recent file list view in 6.4 branch.
I don't think it's related to 6.4. The problem of bug 89394 was re-introduced with https://git.libreoffice.org/core/+/43446fa03995fb5d1379fc0afbeec36c9dedfde2, where each shown file was read to check if it's encrypted. That was for v.6.1. Steps to reproduce: 1. Open registrymodifications.xcu in the user profile [1]; 2. Replace all "/org.openoffice.Office.Histories/Histories/org.openoffice.Office.Histories:HistoryInfo['PickList']" entries with these two lines: > <item oor:path="/org.openoffice.Office.Histories/Histories/org.openoffice.Office.Histories:HistoryInfo['PickList']/ItemList"><node oor:name="http://1.2.3.4/doc.odt" oor:op="replace"><prop oor:name="Title" oor:op="fuse"><value>pwdLorem</value></prop><prop oor:name="Filter" oor:op="fuse"><value>writer8</value></prop><prop oor:name="Password" oor:op="fuse"><value></value></prop></node></item> > <item oor:path="/org.openoffice.Office.Histories/Histories/org.openoffice.Office.Histories:HistoryInfo['PickList']/OrderList"><node oor:name="0" oor:op="replace"><prop oor:name="HistoryItemRef" oor:op="fuse"><value>http://1.2.3.4/doc.odt</value></prop></node></item> 3. Try to start LibreOffice. => it will take between 20 and 30 s to launch, because it would try to access http://1.2.3.4/doc.odt, which does not immediately reject, and thus the read attempt will timeout before the load will continue. Tested with Version: 6.1.5.2 (x64) Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU threads: 12; OS: Windows 10.0; UI render: GL; Locale: ru-RU (ru_RU); Calc: group threaded OK in Version: 6.0.0.1 (x64) Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU threads: 12; OS: Windows 10.0; UI render: default; Locale: en-US (ru_RU); Calc: group A proper fix would be drawing default *module* thumbnail on opening start center (detected from document extension, or from last used filter, which is available in the entries, i.e. without any actual file access); then retrieve all necessary information (encrypted status, availability (bug 101302), anything else) asynchronously in multiple threads, updating the thumbnails as the data is available. [1] https://wiki.documentfoundation.org/UserProfile
*** Bug 134047 has been marked as a duplicate of this bug. ***
(In reply to Mike Kaganski from comment #1) > I don't think it's related to 6.4. The problem of bug 89394 was > re-introduced with > https://git.libreoffice.org/core/+/43446fa03995fb5d1379fc0afbeec36c9dedfde2, > where each shown file was read to check if it's encrypted. That was for > v.6.1. I doubt that, because I can clearly reproduce this behavior with 6.4 but NOT with 6.3. So I still believe that the introduction of the Icon-Overlay in Start Center in 6.4 is the reason for this regression. I'd prefer to set earliest affected version back to 6.4.x. In the end, it doesn't matter if its due to encryption-check or mime-type sniffing, loading start center should NOT trigger access to all recent files.
(In reply to OfficeUser from comment #0) I'd suggest changing the title of this bug from "LibreOffice hangs if recent files are not accessible" to "Start Center hangs if recent files are not accessible" or "LibreOffice Start Center hangs if recent files are not accessible" (even though its obvious that it belongs to LibreOffice, since its the LibreOffice Bugtracker ;)). I think this bug would be easier to find with the Tag "Start Center" in the title. I could change it my own, but I don't want to override you ;)
(In reply to bugzilla2 from comment #3) It might of course had worsened with the fix for tdf#125756. However, that partial regression is undoubtedly not to be fixed by its own, and the core problem *is* the one introduced in the commit mentioned in comment 1. Please do not change the earliest version, since it's analyzed, the problem identified, and the proper way to fix described.
(In reply to Mike Kaganski from comment #5) > It might of course had worsened with the fix for tdf#125756. However, that > partial regression is undoubtedly not to be fixed by its own I disagree. There's absolutely no reason to check for encryption status while just getting the default image for the given module to be used as an overlay. But that exactly what the overlay code does, by calling RecentDocsView::getDefaultThumbnail which has the encryption check. Before introducing the overlay feature, the encryption check was triggered only for files which didn't have thumbnails stored in the user profile, which usually not the case. > and the core problem *is* the one introduced in the commit mentioned in comment 1. Note that for the case there is no thumbnail in the user profile, we were trying to read the file anyway to get the thumbnail stored inside it, way before the mentioned commit.
It was kind of copy/paste coding. I agree with removing the encryption part from the thumbnail as this information does not contribute to the actual reason for the MIME type icon, to see what content a file contain resp. what module would be used.
(In reply to Maxim Monastirsky from comment #6) > > and the core problem *is* the one introduced in the commit mentioned in comment 1. > Note that for the case there is no thumbnail in the user profile, we were > trying to read the file anyway to get the thumbnail stored inside it, way > before the mentioned commit. You mean the "aThumbnail = ThumbnailView::readThumbnail(rURL);" call in RecentDocsViewItem::RecentDocsViewItem? Yes. Still, it needs to be also done in a dedicated thread. But I see your point, and taking the overlay icon is of course should be re-implemented to not try to read encrypted status.
Bug still present in 6.4.5.2
*** Bug 140875 has been marked as a duplicate of this bug. ***
*** Bug 144972 has been marked as a duplicate of this bug. ***
*** Bug 146219 has been marked as a duplicate of this bug. ***
Is this bug supposed to be about remote files only, or also about local files which have become inaccessible? If it's the former, than my dupe is not a dupe; and if it's the latter, then the title is a bit misleading.
(In reply to Eyal Rozenberg from comment #13) I reproduce the issue regarding remove files on Nextcloud (webdav), but I do not reproduce the hang with a local file deleted. So if it is slow or hangs with deleted local file, then it should not be a duplicate. > If it's the former, than my dupe is not a dupe But which bug are you referring to?
https://gerrit.libreoffice.org/c/core/+/126849
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2f848eb5dc6f6f9344f250ac9860065130aaf436 tdf#131850: avoid encryption check for recent docs overlay It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The regression from https://git.libreoffice.org/core/+/d43c6fa220524a09c0b24cbb5bc03c4456cd2515 is now fixed. Note that for password-protected files, the check will still be made, because their thumbnails are not stored in the thumbnail cache. One possible way forward (in addition to proper async IO) could be storing generic thumbnail in cache for password-protected files - but that would be theming-unfriendly, since it would show "alien" thumbnails after user changes icon theme. See comment 1, and use bug 101302 for the rest.
(In reply to Kevin Suo from comment #14) > But which bug are you referring to? Bug 140875.
(In reply to Eyal Rozenberg from comment #18) > Bug 140875. ... which was unduped by yourself on 2021-03-08 (for no good reason but misunderstanding the workflow and goals of the bug tracker): https://bugs.documentfoundation.org/show_activity.cgi?id=140875
(In reply to Mike Kaganski from comment #17) The hang/slowness still exists with the following scenario: 1. Mount a webdav folder in your system using the file manager. 2. Open a file with LibreOffice from the mounted webdav folder, then quit libreoffice. 3. Unmount the webdav folder from your file manager. 4. Run libreoffice. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 453c5b6214654b440fe1d3e926cddfb695e17f10 CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.4-CN Calc: threaded
(In reply to Kevin Suo from comment #20) Could you please check which call stack produces the hang? Thanks!
(In reply to Mike Kaganski from comment #21) Will try, but I guess it's in: sfx2/source/control/recentdocsview.cxx:73 bool IsDocEncrypted(const OUString& rURL) { ... uno::Sequence<uno::Any> aArgs{ uno::Any(rURL), uno::Any(embed::ElementModes::READ) }; uno::Reference<embed::XStorage> xDocStorage ( xStorageFactory->createInstanceWithArguments(aArgs), uno::UNO_QUERY); ... } In case the rURL is a remote file, it tries to read that file to check if it is encrypted. In my opinion we should not check encryption for remote files when we start up the application. Check encryption is only needed when we click that remote file for viewing or editing (so that the user need to provide a password). Otherwise, if is certainly slow especially if the network is slow. I am aware that to draw the thumbnail we need to read that file. But is it really useful to draw a thumbnail for the remote files? How about cache the remote file thumbnail at the time when that file was initially opened, or simply draw a dummy/generic thumbnail for all those remote files?
(In reply to Kevin Suo from comment #22) The commit above made sure that when there is a cached thumbnail of a document (no matter if it's local or remote, and unencrypted remote files should have that cached thumbnail), the encrypted status is *not* checked. So if *that* still happens, then we need a call stack to try to understand what goes on; but I *suppose* there might be another place that does that - which then needs an own issue. Wrt not checking remote files - that's not possible, since great proportion of work - especially in corporate use of office suites - happens exactly with remote documents, so treating them as second-class citizens is wrong.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/214364584d3a247a70eed42ca7101b675125bf43 tdf#131850: avoid encryption check for recent docs overlay It will be available in 7.3.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Mike Kaganski from comment #23) > Wrt not checking remote files - that's not possible, since great proportion > of work - especially in corporate use of office suites - happens exactly > with remote documents, so treating them as second-class citizens is wrong. I don't believe your metaphor works here. Documents are not like people. In particular - how about drawing the thumbnail asynchronously if it's not cached? i.e. start with no-thumbnail, let user proceed with their interaction, and as soon as the thumbnail is available, draw it?
(In reply to Eyal Rozenberg from comment #25) > how about drawing the thumbnail asynchronously if it's not > cached? i.e. start with no-thumbnail, let user proceed with their > interaction, and as soon as the thumbnail is available, draw it? Sometimes I doubt people can read. After I wrote in comment 1: (In reply to Mike Kaganski from comment #1) > A proper fix would be drawing default *module* thumbnail on opening start > center (detected from document extension, or from last used filter, which is > available in the entries, i.e. without any actual file access); then > retrieve all necessary information (encrypted status, availability (bug > 101302), anything else) asynchronously in multiple threads, updating the > thumbnails as the data is available. ... after I referred to that in comment 17; after I repeated that in bug 101302 comment 32 (confirming what Maxim wrote in bug 101302 comment 8), I get someone suggesting me to consider async IO. Oh my!...
(In reply to Mike Kaganski from comment #26) Sorry.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/bda87ece5bd8755384213aa6b01524324c153893 tdf#131850: avoid encryption check for recent docs overlay It will be available in 7.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #28) > Mike Kaganski committed a patch related to this issue. > It has been pushed to "libreoffice-7-2": > > It will be available in 7.2.6. Thanks for the Patch, can't wait to see that in production builds :)
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-2-5": https://git.libreoffice.org/core/commit/ea5c9ca9950a23860daaccb658bdbed76a038a2a tdf#131850: avoid encryption check for recent docs overlay It will be available in 7.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 146340 has been marked as a duplicate of this bug. ***
Following an update to 7.2.5 I did the following: 1. Worked on odt files on a remote share mounted using ssh through my vpn. 2. Closed LO. 3. Unmounted the share. 4. Disconnected the VPN. 5. Attempted to open a local file, via referrer (firefox) and through terminal. LO froze on boot every time. Libreoffice 7.2.5.1-1.6.x86_64 OpenSuSE Tumbleweed 5.14.11-1 Can't get any more information because LO won't launch.
(In reply to fnorbenden from comment #32) You may rename you lo user profile so that it starts with a fresh one, to continue with your work: /home/<your_username>/.config/libreoffice
*** Bug 147152 has been marked as a duplicate of this bug. ***
See ^ duplicate bug for my workarounds, either removal of sftp entries from registrymodifications.xcu or disabling recent documents. So can you conifrm if 7.2.5.1 relesed on 2021-Dec-14 is not new enough (this is the version I'm using), but 7.2.5.2 released on 2021-Dec-29 would be?
(In reply to Timo Jyrinki from comment #35) Commit ea5c9ca9950a23860daaccb658bdbed76a038a2a was applied to libreoffice-7-2 on Fri Dec 17 10:35:41 2021 +0100. So, yes, the fix is available in 7.2.5.2 (i.e. 7.2.5 RC2, i.e. the final 7.2.5 version you can download from the https://www.libreoffice.org/download/ link), but not in 7.2.5.1 (i.e. 7.2.5 RC1).