I'd say - dupe of bug 131850, and subject to bug 131850 comment.

*** This bug has been marked as a duplicate of bug 131850 ***

This is not a duplicate of bug 131850. After the fix in bug 131850, this bug still exists.

Created attachment 176961 [details]
GDB Backtrace when unmounted

This is the gdb backtrace when the remote nextcloud (webdav) folder is unmounted in the Gnome File Manager.

Steps:
1. Mount a nextcloud/webdav folder in the system File Manager.
2. Open a file with LibreOffice from that fodler.
3. Unmount that nextcloud webdav folder. 
(this is common, for instance I mounted that remote folder yesterday, opened a file in LibreOffice, then I close my computer, and today I start libreoffice for today's work)

As indicated in the stack calls, when LibreOffice is launched, it tries to mount the remote folder in order to get the thumbnail information of the file. 

For a webdav file:
* It hangs for 15s, then become active again and the start center opens. Problem is that, LibreOffice does not have the necessary information (username, password etc) to mount the remote instance, thus the mount fails for sure.
* Even worse, after it become active, if I try to create a new Calc document in the start center, it hangs for another 15s. The same also happens when I click the "X" *below* the main "X" of the Window Manager, or if I mouse-hover through the Files menu (so that the Recent Files submenu is touched), it hangs for another 15s.

I then tried with a sftp file:
* A dialog pops up asking for password at the time of startup. This is good, but if there are many remote sftp files opened before and the folders were unmounted, then should it popup many dialogs to ask for password for each of them?
* Interestingly, if I click "Cancel" on the Password dialog, the dialog pops up for the 2nd time, then I click cancel again, Start Center opens. Then I create a New Calc file, the Password dialog pops up again. I clicked cancel (2 times), a new Calc document is created. Then I try to close the Calc document by clicking on the 'X" button *below* the main "X" button of the window manager, so that LibreOffice goes to the Start Center again, but this time the Password dialog shows up again. 
* Also, after a new Calc document is created, and I mouse-hover within the Files menu and the "Recent Document" submenu was touched, the Password dialog pops up again.

Created attachment 176962 [details]
GDB Backtrace when mounted

This is the gdb backtrace when the remote Nextcloud/webdav folder is mounted.

As indicated in the backtrace, libreoffice tries to communicate with the remote server in order to get the file information.

This is OK if the remote file is located over a local network, but in many cases there may be many Recent Files items, some of which may be in local network, some may be far away, and some may be unreachable due to network problems or server down. This will make LibreOffice slow when I go to the start center, or create a new document, or close the current file (not the main window), or mouse-hover to the Files menu, as explained in my comment above.

Both stacks point at this line:

  https://opengrok.libreoffice.org/xref/core/framework/source/uielement/recentfilesmenucontroller.cxx?r=9f326792#213

It seems it depends on some setting (defaulting to true in some VCL plugin maybe?) that allows document thumbnail as menu icon; and that information is requested from SvFileInformationManager, which simply tries to read the data from the URL.

It seems logical to follow the same path as used in RecentDocsView::Reload, which tries to use the cached thumbnail from history, and only falls back to reading from file, when the cached image is not available. This would already avoid most attempts to read from remote files.

As with bug 131850 and bug 101302, the greater - and separate - problem is to implement async procedure for those documents that have no cached images - since they still need to be accessed to get their image, that should be done in dedicated threads, not blocking UI. But I'd track that separately, after fixing the "use cached image when available" part here.

Or - maybe even disable fetching the document in case its cache is not present? E.g., Start Center does that: it only shows cached thumbnail, *or* generic image, but does not read the document to get the image (it only accessed the document to get its metadata like "is it encrypted").

(Not confirming myself, since I can't repro on my system lacking necessary environment, but the problem seems to be reasonably clear.)

(Also it's interesting, if password-protected files would show proper dedicated icons in the menu (as in Start Center) - or they would use generic icons - but that's unrelated to this issue, and should be investigated and filed separately.)

(In reply to Mike Kaganski from comment #6)

Ah - sorry, I was thinking too complicated.
RecentFilesMenuController::fillPopupMenu doesn't use file thumbnail at all. It calls SvFileInformationManager::GetImageId to *get identifier of generic image*, which tries to check if the URL is directory (and thus calls GetImageId_Impl passing bDetectFolder = true). But RecentFilesMenuController::fillPopupMenu itself doesn't need directory detection. So the solution is to just avoid use of SvFileInformationManager::GetImageId, and use SvFileInformationManager::GetFileImageId instead, that calls GetImageId_Impl with bDetectFolder = false.

https://gerrit.libreoffice.org/c/core/+/126943

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/866b569b58a13dab2da247aef70822933353663c

tdf#146219: don't try to detect if a recent file is a directory

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.

This should be fixed now - but as I can't test, could you please test and report back? Thanks!

(In reply to Mike Kaganski from comment #10)
I confirm that this is now fixed on master. Thank you!

And this also affects other branches, so I assume you are going to backport this to 7.2 and 7.3 branches as well.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/c247023dfd10bef22b9ff5a85cc44febfc90e951

tdf#146219: don't try to detect if a recent file is a directory

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.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/37c617af996bf5f9c4be08a1245940d00668a64b

tdf#146219: don't try to detect if a recent file is a directory

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.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-2-5":

https://git.libreoffice.org/core/commit/8d111cee975a1a8f9f3ed1773e93fb63c7565a7a

tdf#146219: don't try to detect if a recent file is a directory

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 146058 has been marked as a duplicate of this bug. ***

*** Bug 147152 has been marked as a duplicate of this bug. ***