1798791 - PDF Viewer blocks/freezes when trying to save to unavailable network drive

Status: REOPENED

(Core :: Widget: Win32, defect, P3)

Description

[JS]

Steps to reproduce:

• Connect to a network drive via VPN
• Open a PDF in firefox or thunderbird
• Save PDF to network drive
• disconnect VPN
• Click on the save button again

Actual results:

The PDF Viewer just wont react when you click the save button. It feels like the click is not processed. Probably because it's trying to access the network drive which is not accesable anymore. The saving window will just pop up after a timeout of a few minutes!?

Expected results:

Open the "saving dialog window" immediately. Show a warning that the network drive is not accesible or just switch to a default path.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::PDF Viewer' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Monica Chiorean]

Seems similar to bug 1785046.
Reporter do you agree?

Comment 4

[Calixte Denizet (:calixte)]

Saving a pdf will finally lead to call saveUrl.
So I'd say that it isn't an issue on the pdf.js' side but likely something wrong when trying to save the blob.
:Gijs, what do you think ?

Comment 5

[:Gijs (he/him)]

What OS are you seeing this on, and what kind of network drive (samba/Windows share, or something else)?

I suspect (but can't test this out without some more specifics) that the slowness is in the OS code that tries to open the network location in the OS filepicker when saving, because it's the last location to which you saved a file so Firefox reopens the filepicker with that location as the default. I don't know that we can really predict that slowness or deal with it without bug 1677170.

Comment 6

[JS]

It's on Windows 10. Should be a Windows share. Do you know how I can check that?

What you suspect sounds exactely how it feels in practice.
Actually I just remembered that I observed a simillar problem with a network printer that was turned off. But I don't remember exactely.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Dave Townsend [:mossop]]

Can you put a severity on this Gijs?

Comment 9

[:Gijs (he/him)]

I think a solution here would need to be found on the widget level - it doesn't really make sense to push the responsibility of figuring out if the default path with which we open the filepicker is going to be (quickly) available to each of the consumers.

As a result, moving this to the core::widget code like bug 1677170 - I'm not sure if fixing that bug will "automatically" fix this one and if this one should just be duped. I somewhat suspect not, but I'll leave that to :spohl as triage owner of that component.

It may be worth, in either case, asking the perf team to assess a performance severity for whichever bug stays open, given the impact - hanging the main process for several minutes is pretty terrible...

Comment 10

[:Gijs (he/him)]

(In reply to JS from comment #6)

It's on Windows 10. Should be a Windows share. Do you know how I can check that?

And I see I didn't answer this - I'm afraid I don't know, if the network drive is not fully under your control (or under the control of someone you know and can ask). I expect the samba/shared-drive protocol has some version identifier of sorts but I don't know for sure or how you'd go about extracting that information - sorry!

Comment 11

[Ray Kraesig [:rkraesig]]

(In reply to JS from comment #6)

It's on Windows 10. Should be a Windows share. Do you know how I can check that?

From PowerShell, as Administrator, run Get-SmbConnection. The various SMB shares will be listed; the SMB protocol version for each share will be given under the "Dialect" field.

If the relevant network share isn't there, then it's not an SMB share. (I'm not sure how to go about finding out what it actually is, in that case; I'd start with right-click → Properties and hope that turned up a lead.)

---

(In reply to :Gijs (he/him) from comment #9)

As a result, moving this to the core::widget code like bug 1677170 - I'm not sure if fixing that bug will "automatically" fix this one and if this one should just be duped. I somewhat suspect not, but I'll leave that to :spohl as triage owner of that component.

Well, Core :: Widget probably is the right place for this. If the file picker is taking a long time to show up because of an unresponsive or high-latency network share, though, I don't think moving it out-of-process would change that.

I'm also not sure how we should handle it, from a user's perspective — the current situation is clearly suboptimal, but the best I've got is to mimic the behavior of older single-threaded Windows applications and have the relevant Firefox tab go unresponsive while the cursor switches to a spinner.

Comment 12

[:Gijs (he/him)]

(In reply to Ray Kraesig [:rkraesig] from comment #11)

(In reply to :Gijs (he/him) from comment #9)

As a result, moving this to the core::widget code like bug 1677170 - I'm not sure if fixing that bug will "automatically" fix this one and if this one should just be duped. I somewhat suspect not, but I'll leave that to :spohl as triage owner of that component.

Well, Core :: Widget probably is the right place for this. If the file picker is taking a long time to show up because of an unresponsive or high-latency network share, though, I don't think moving it out-of-process would change that.

I'm also not sure how we should handle it, from a user's perspective — the current situation is clearly suboptimal, but the best I've got is to mimic the behavior of older single-threaded Windows applications and have the relevant Firefox tab go unresponsive while the cursor switches to a spinner.

If we expose an async, promise-based API for filepicker use to JS, then we wouldn't need to block on the filepicker when we invoke it from frontend code, which would unblock the UI. Right now I'm assuming we block the entire UI thread (because it's all mainthread in the parent process, right?).

For this specific case though, I think comment 0 kind of hints at what should probably happen: if we detect a network drive is the input path requested for the filepicker (could be messy, but there should be a reasonably cheap way of guessing, I think?), can we signal from a different thread once it's taken some time to open it, and then switch to some "safe" default (maybe $desktop or w/e) ? Or could we pre-emptively detect this case by calling some cheaper API to go "hey is this network drive still available" ?

(I don't have the setup described in comment 0 including a VPN etc., but it'd be interesting to learn what other apps, e.g. notepad or VS Code or whatever, do in this situation...)

Comment 13

[Ray Kraesig [:rkraesig]]

(In reply to :Gijs (he/him) from comment #12)

If we expose an async, promise-based API for filepicker use to JS, then we wouldn't need to block on the filepicker when we invoke it from frontend code, which would unblock the UI. Right now I'm assuming we block the entire UI thread (because it's all mainthread in the parent process, right?).

We do, although it doesn't have to be that way. Unlike on macOS, there's no OS-mandated requirement that the file-selector dialogs be opened from the main thread. (Although now that I say that, I realize that this may also occur on macOS...)

For this specific case though, I think comment 0 kind of hints at what should probably happen: if we detect a network drive is the input path requested for the filepicker (could be messy, but there should be a reasonably cheap way of guessing, I think?), can we signal from a different thread once it's taken some time to open it, and then switch to some "safe" default (maybe $desktop or w/e) ? Or could we pre-emptively detect this case by calling some cheaper API to go "hey is this network drive still available" ?

We can certainly detect whether opening the file dialog is taking a while — but once we've actually started to open it, I don't think we can safely abort. (Doing that would require an out-of-process file picker. And, honestly, I wouldn't be willing to swear that the process could be successfully killed until after the window showed up.)

In the general case, even Windows can't preemptively detect whether that the network drive is still available. (For example: on a multi-network-interface device, if one network interface goes down, the drive may be reachable over another; Windows has no way to determine whether or not it is other than to query the network and wait for a timeout. Alternatively, even if the network interface is still up, the server at the other end may have quietly failed.)

(I don't have the setup described in comment 0 including a VPN etc., but it'd be interesting to learn what other apps, e.g. notepad or VS Code or whatever, do in this situation...)

I'm pretty sure they just go unresponsive (i.e., stop processing Windows messages) until the file picker responds. If they're unresponsive for long enough, Windows will override their chosen cursor with the wait-cursor and, possibly, fade out the window. (This is what my previous comment about mimicking behavior was based on.) VSCode is Electron-based and so may have some fancier response, but I'd be very surprised if Notepad did anything else.

Given that, I suspect just manually switching the cursor to a wait-cursor after... say, 200ms?... is probably sufficient.

Comment 15

[Anton Masalatkin]

I encounter this in a slightly different environment:
OS: Windows 10
Firefox Version 121.0 (64-bit)
PDF file open on network drive (no VPN)
Network OS: NAS, QNAP 5.*

Steps to reproduce:

• open PDF file on network drive
• disconnect NAS
• try to click CTRL+S to save changes in PDF, e.g. added caption: no Save As dialog open
• try to refresh the page: browser hangs

Attempt to click on a Window leads to Windows standard "Report an issue" window.