Closed Bug 1689315 Opened 3 years ago Closed 2 years ago

Moving a window to a Portrait monitor causes Firefox to strobe and freeze taking up a lot of CPU and eventually crashing


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

Firefox 85





(Reporter: richardjmoore, Unassigned)


(Keywords: multi-monitors, Whiteboard: [win:multimonitors][win:sizing])

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

Steps to reproduce:

Move a firefox window with many tabs from a landscape monitor to a Portrait monitor.

This move can either be manual via user interaction or it can be when the computer is plugged into an external portrait display and the window is moved automatically.

This is on Windows 10 20H2 and occured with all versions of Firefox 84 and also Firefox 85.

I only recently installed a portrait monitor so am unaware and unable to give any indications of when this might have started to happen.

Actual results:

Firefox does not adjust it's UI elment approriately with the tab bar and window controls enlarged and the maximise/minimise/close buttons off the screen.
The web page content then strobes this happens on normal web pages and also PDFs that.
The whole application, even Firefox windows on other screens, become unresponsive.
Firefox takes up a lot of CPU and GPU resource.
Firefox may sometimes recover and adjust to the new page after 30 seconds or so. Other times Firefox crashes or it needs to be force stopped.

Expected results:

The UI adjusts to the portrait display and the application continues working.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Graphics
Product: Firefox → Core

Hi, could you capture a profile using so we can dig into what's happening? In the profiler settings choose the "Firefox graphics" preset. Once you have captured a profile, you can share it by clicking the upload button on the top right corner of the profile viewer and paste the upload link here.

Blocks: gfx-triage
Flags: needinfo?(richardjmoore)
Flags: needinfo?(richardjmoore)

Thanks. By the look of the profiles, the main thread of the parent process appears to ve constantly receiving events and deciding to update the size of the window (which triggers the CPU and GPU intensive work, but the orrot of the issue is this size onstantly changing). Perhaps there's something we can do to filter out these constant size changes.

Severity: -- → S2
Keywords: multi-monitors
OS: Unspecified → Windows
Hardware: Unspecified → Desktop
Component: Graphics → Widget
No longer blocks: gfx-triage

Is this still occurring?

Severity: S2 → S3
Component: Widget → Widget: Win32
Flags: needinfo?(richardjmoore)
Priority: -- → P3
Whiteboard: [win:multimonitors][win:sizing]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:spohl, 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 auto_nag documentation.

Flags: needinfo?(richardjmoore) → needinfo?(spohl.mozilla.bugs)
Closed: 2 years ago
Flags: needinfo?(spohl.mozilla.bugs)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.