Closed Bug 1881950 Opened 1 year ago Closed 1 year ago

File dialog's file-type selector hangs browser when it would overlap a different screen with different DPI scaling

Categories

(Core :: Widget: Win32, defect)

Firefox 125
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: scineram, Unassigned)

Details

Attachments

(1 file)

Attached image ff_tw_selector.png

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

Steps to reproduce:

  1. Start FF in troubleshooting mode.
  2. Start composing new tweet.
  3. Click media upload button.
  4. In the file selector window try changing the file extension filter from "All Supported Types".

Actual results:

  1. A drop down list to appear if only with 1 option. Or at least just refuse to open the drop down menu.

Expected results:

  1. Behold the entire window hanging, and eventually all other browser windows.

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

Component: Untriaged → Widget: Win32
Product: Firefox → Core

I need to amend. My file selector window was maximized as seen in image. If I shrink it (Windows + Leftarrow) the file extension filter can be opened and nothing breaks. But if I reenlarge it by double clicking marked triangle in bottom right corner then open the filter the browser hangs.

The entire browser? That... shouldn't happen, for multiple reasons. (This is almost certainly a crash bug in the Windows file-dialog, but Nightly is supposed to protect the browser from those!)

  • In about:config, what is widget.windows.utility_process_file_picker set to?
  • If you go to about:crashes, is there a recent crash associated with this? If so, can you post the crash ID here?
  • Is this a recent failure? (That is, did this work last month?) If so:
    • ...does reinstalling Firefox fix it?
    • ...can you use mozregression to narrow down when the failure was introduced?
  • Does this happen at other resolutions or DPI scalings?

Behold the entire window hanging, and eventually all other browser windows.

What sort of hang? Do the windows simply stop responding, or do you eventually get a "this application is not responding" dialog? If there's an animation or video playing in the background, does it continue or also freeze?

Flags: needinfo?(scineram)

widget.windows.utility_process_file_picker is 0. There are no crash reports from this. I remember seeing this some time ago, so probably nothing new. The reproducer is just rare and specific.

The screen is FHD, but there is a QHD extended display to the right at 200% scaling with another browser window on it typically. If Youtube plays in that the video and audio keeps playing but nothing else responds including playback controls. Eventually the "not responding dialog" comes up to kill the browser. Will try reproducing on an office PC tomorrow.

Flags: needinfo?(scineram)

It is the scaling. Just now I reproduced even when the selector window isn't full screen, only quarter but snapped to the right of this screen. But once I change the scaling on the QHD display on the right to 100% there is no hang. In fact the file extension list crosses over to the other screen.

In fact if I change the scaling to 100% WHILE the browser is hung it RESUMES.

(In reply to John from comment #5)

It is the scaling. Just now I reproduced even when the selector window isn't full screen, only quarter but snapped to the right of this screen. But once I change the scaling on the QHD display on the right to 100% there is no hang. In fact the file extension list crosses over to the other screen.

Just to confirm: QHD = 2560 x 1440, FHD = 1920 x 1080?

Not that it matters; I've successfully reproduced this locally with a release-channel version with completely different resolutions. It seems that the crash occurs whenever the file extension list would be partly displayed on the other screen. (I've no idea why; Visual Studio 2022, for example, doesn't crash when this happens.)

Based on the stack I'm seeing when I break into it with a debugger (and your note about unfreezing it by changing the scaling), I suspect what's going on is that the file dialog is actually stuck in an infinite loop of trying to resize the file extension list window, and that the parent process is being flooded with useless messages (probably window-change or focus-change).

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: twitter file selector hangs browser → File dialog's file-type selector hangs browser when it would overlap a different screen with different DPI scaling

(For ease of reproduction and debugging: instead of rescaling the second monitor to resolve the hang, it's also possible to simply rearrange the monitor geometry such that the file-type list would no longer extend onto another monitor.)

Correction: this does happen in Visual Studio 2022, under the right conditions. It also happens in Chromium and Edge in basically the same conditions it happens for us. A strictly-local URL for testing is below:

data:text/html,<input type="file" accept="audio/*,video/*,image/*">

The first thing to note here is the resultant absurdly-long "All Supported Types" entry (or in Chromium, "Custom Files"). In my testing, this extends not merely beyond the originating screen but beyond the next screen — the far-right-hand side is off the edge of the monitor. This doesn't normally happen with any option in Visual Studio 2022, but I was able to force it by setting my 1280 x 1024 monitor to 150% scaling, thereby hanging VS 2022 just like the browsers.

The second is that it's not necessary to click on the file-type dropdown: what's actually inducing the infinite loop is the (same-width) tooltip that appears upon hovering over it.

Unfortunately, my guess that "the parent process is being flooded with useless messages" is not correct: the parent process simply isn't receiving any input-messages whatsoever. (It does get WM_GETICON messages, and our internal wakeup messages are also processed, so it's not as simple as "the message queue is stalled"... but we don't get input messages posted to any other window in the whole process, as far as I can tell — even when the browser-window process isn't the file-dialog process.)

Both of these issues are ultimately going to have to be resolved by Microsoft. I'll file a bug with them.

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

For more information, please visit BugBot documentation.

Flags: needinfo?(rkraesig)

The bug has been filed in Feedback Hub, with the full repro steps (using Edge, to make the point clear) and a link here -- I just missed actually closing the issue.

As this is an MS bug, closing as RESOLVED INVALID.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(rkraesig)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: