1849300 - Firefox become not responding while printing or change download directory

Status: RESOLVED INCOMPLETE

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

Description

[mail]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

Print web page to PDF ("Save to PDF" or "Adobe PDF") or change Download directory in settings

I tried to some troubleshooting but not worked:

• clear download history
• troubleshoot mode
• change computer

Actual results:

Firefox window become not responding

Expected results:

Print or change settings successfully

Comment 1

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

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

Comment 2

[David G King]

I've been getting the same when saving a PDF, or when trying to upload a file to a web page.
Win 11 22H2 (22621.2134) on Firefox 117.0 (Beta)

Comment 3

[Jonathan Kew [:jfkthame]]

I can't reproduce this; saving to PDF works fine for me on Windows, and so does changing the Download directory.

This sounds to me like it might be some kind of filesystem permissions issue. Bob, any thoughts?

Comment 4

[Bob Owen (:bobowen)]

(In reply to Jonathan Kew [:jfkthame] from comment #3)

I can't reproduce this; saving to PDF works fine for me on Windows, and so does changing the Download directory.

This sounds to me like it might be some kind of filesystem permissions issue. Bob, any thoughts?

I can't reproduce either.
I think there has been some work recently on the file picker, but I don't think any of it has made it to release or if it would theoretically affect these things (rkraesig might know).
I don't think it would affect the Adobe PDF printer driver.
None of this should be attempting file access from a child process where we would have sandboxing.

I guess it could be permissions on the parent process - are you running Firefox in an unusual way?
If this is a recent issue, are you able to find a regression using mozregression?

Comment 5

[Ray Kraesig [:rkraesig]]

(In reply to Bob Owen (:bobowen) from comment #4)

I think there has been some work recently on the file picker, but I don't think any of it has made it to release or if it would theoretically affect these things (rkraesig might know).

It hasn't (except possibly bug 1838244). That said, I think the file-picker to save a PDF is launched from from winspool.dll (or similar), rather than from Firefox code directly? But still in-process (ouch), so a permissions problem on the parent process sounds plausible.

Comment 6

[David G King]

In my case, whenever I do something to cause the Windows Filepicker to appear, I know that Firefox will shortly stop responding. So, I don't see it as a purely Firefox bug as the problem only seems to appear when interacting with a new Windows process. I run Firefox Beta, and I used to run Win 11 Insider (but gave up). So permissions could be an issue. Of course, I'm no expert :)

Comment 7

[Bob Owen (:bobowen)]

(In reply to David G King from comment #6)

In my case, whenever I do something to cause the Windows Filepicker to appear, I know that Firefox will shortly stop responding. So, I don't see it as a purely Firefox bug as the problem only seems to appear when interacting with a new Windows process. I run Firefox Beta, and I used to run Win 11 Insider (but gave up). So permissions could be an issue. Of course, I'm no expert :)

This sounds a little more like it might be a Windows message processing issue.
If this is something that happened recently are you able to use mozregression to find a version that works and then use the bisection feature to try and find what change introduced the issue?:
https://mozilla.github.io/mozregression/

Also, do either of you have any unsubmitted crashes in about:crashes?
It's possible they might be related, so would you submit them and paste the URLs into a comment.

Comment 8

[David G King]

Nothing in about:crashes. Not Responding isn't a Crash it seems.
I'll do some investigation with mozregression to see what I find.

Comment 9

[mail]

I tried printing to PDF and changing Download directory, both worked fine.

Tested version:

Firefox
Version 118.0b2
Build ID 20230829180158

Windows 10 22H2 Build 19045.3324

Comment 10

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

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

For more information, please visit BugBot documentation.

Comment 11

[Daniel Holbert [:dholbert]]

Given comment #6 ("whenever I do something to cause the Windows Filepicker to appear") and comment 2 ("trying to upload a file to a web page"), I don't think it makes sense to classify this under printing. Reclassifying as Widget|Win32.

This also is extremely similar to a related issue under some Linux configurations: bug 1774062 (similar enough to the point that I was getting ready to mark this as a duplicate until I noticed you mention Windows :) ). I think that one's mostly settled as being a bug outside of Firefox (and it's specific to the save/open key-combinations, whereas your issue seems to be with filepicker-dialogs-spawned-by-buttons); so there's probably no actual connection between the bugs under the hood. I'll add it to the "see also" field, though.

(In reply to David G King from comment #8)

Nothing in about:crashes. Not Responding isn't a Crash it seems.

On Linux at least, we can use kill -11 to forcibly crash Firefox when it's hanging, in a way that triggers a crash report... I wonder if there's a similar lever we can use on Windows? (Bob, do you happen to know?)

I'll do some investigation with mozregression to see what I find.

Thanks! That's looking like our best potential source of clues at the moment, if this is indeed something that only started happening recently.

Comment 12

[Daniel Holbert [:dholbert]]

(ni=bob is regarding the windows equivalent to kill -11 to generate a crash report)

Comment 13

[Bob Owen (:bobowen)]

(In reply to Daniel Holbert [:dholbert] from comment #12)

(ni=bob is regarding the windows equivalent to kill -11 to generate a crash report)

gsvelto is probably the best person to answer that.

Comment 14

[Gabriele Svelto [:gsvelto]]

You can try using crash-firefox however it doesn't always work. If it does work, submit the crash report, relaunch Firefox, go in about:crashes then paste the link to the crash here.

Alternatively one can grab a minidump of the hung process via the task manager. Right-click on the hung process and select "Create Dump File". If you do that do not attach the dump file to this bug. Share it with me via e-mail so I can analyze it and extract a stack trace.

Comment 15

[Ray Kraesig [:rkraesig]]

In Firefox Nightly we now open the file-picker in a separate process by default. This behavior can be enabled in Beta or Release, too, by going to about:config and setting widget.windows.utility_process_file_picker to 2. (Restarting Firefox should not be necessary.) As noted in comment 5, this will not affect file-picker dialogs spawned from "Print to PDF", because we don't have direct control over that file-picker and haven't (yet?) moved printing out-of-process.

If you set the above value, does it change the behavior you're seeing?

Alternatively, NirSoft's ShellExView allows disabling third-party shell extensions. (Testing this will require restarting Firefox, if the file-dialog is being opened in the main process.) Is there any such extension which, if disabled, makes this issue go away?

(In reply to David G King from comment #8)

Nothing in about:crashes. Not Responding isn't a Crash it seems.
I'll do some investigation with mozregression to see what I find.

Did this turn up anything? (In particular, if old versions of Firefox from before you saw this first occur exhibit this behavior when testing, that indicates that it's probably something other than Firefox inducing the delay.)

Comment 16

[David G King]

I didn't find anything, and I haven't seen the problem for some time.

Comment 17

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:rkraesig, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.