File dialog's file-type selector hangs browser when it would overlap a different screen with different DPI scaling
Categories
(Core :: Widget: Win32, defect)
Tracking
()
People
(Reporter: scineram, Unassigned)
Details
Attachments
(1 file)
121.09 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
- Start FF in troubleshooting mode.
- Start composing new tweet.
- Click media upload button.
- In the file selector window try changing the file extension filter from "All Supported Types".
Actual results:
- A drop down list to appear if only with 1 option. Or at least just refuse to open the drop down menu.
Expected results:
- Behold the entire window hanging, and eventually all other browser windows.
Comment 1•1 year ago
|
||
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.
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.
Comment 3•1 year ago
|
||
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 iswidget.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?
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.
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.
Comment 7•1 year ago
|
||
(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).
Comment 8•1 year ago
•
|
||
(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.)
Comment 9•1 year ago
|
||
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.
Comment 10•1 year ago
|
||
The severity field is not set for this bug.
:rkraesig, could you have a look please?
For more information, please visit BugBot documentation.
Comment 11•1 year ago
|
||
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.
Description
•