Viewport is cropped when Firefox window is auto-resized as a result of external monitor getting connected




4 years ago
3 years ago


(Reporter: Harald, Unassigned)



Mac OS X

Firefox Tracking Flags

(firefox43 affected)


(Whiteboard: [gfx-noted])


(1 attachment)



4 years ago
Created attachment 8647124 [details]
Cropped viewport

43.0a1 (2015-08-12) on OSX 10.10.4 (14E46)

When connecting/disconnecting an external screen the Firefox window gets moved/resized. The viewport for each tab stays in a cropped state until I resize the window which then fixes the viewport for every tab.

Comment 1

4 years ago
+2 of my colleagues next to me have the same behavior. It is also reproducible when connecting to Airplay in the meeting rooms.

Comment 2

4 years ago
Maybe related to bug 1125325.

I tested with e10s is disabled.

Comment 3

4 years ago
This probably regressed a few weeks (2-3) back now, sorry to be not more specific.
:handyman, do you know if this might be a regression from bug 1125325?  Seems somewhat related (viewport size/scale stuff w/ external displays on HiDPI Mac).

(The timeframe in comment 3 is a little more recent than that, but Harald might just be overly optimistic about how recently this regressed...)
Component: General → Graphics
Flags: needinfo?(davidp99)
Keywords: regression
Product: Firefox → Core
Summary: Viewport is cropped when window is resizes by system → Viewport is cropped when Firefox window is auto-resized as a result of external monitor getting connected
Keywords: regressionwindow-wanted
Might also be related to Can you check if it still happens with layers.async-pan-zoom.enabled set to false (requires restart)?
Whiteboard: [gfx-noted]

Comment 6

4 years ago
I tried with layers.async-pan-zoom.enabled false and could not see the issue anymore when reconnecting to my external display at home.

Ni? bwalker to verify with his setup as well.
Flags: needinfo?(bwalker)

Comment 7

4 years ago
Oh no, a similar effect just happened with APZ off when I disconnected my screen:

Comment 8

4 years ago
The last screenshot didn't make it:
May be related to issues that have cropped up with WebVR video playback, as captured here:

Currently video textures appear to be misaligned when viewing content in VR mode. Testing requires Firefox Nightly + WebVR Add-on (later available from

Viewing clips of varying sizes [or] entering VR mode on displays of varying resolution both seem to impact the degree of misalignment. Casey Yee from our team speculates:

> Could be that the viewport dimensions are not being reported correctly. It seems that the canvas element itself is sized correctly.
Flags: needinfo?(davidp99)
[restoring needinfo from comment 4, accidentally cleared in comment 9]
Flags: needinfo?(davidp99)
Seeing the patch that :smichaud just posted to bug 1189565 I strongly suspect this has the same root cause that hope that his patch will fix it.
I don't think this is a recent regression, I've seen this for ~forever. (Not using e10s, I've not set any custom options related to APZ.) Viewport is cropped when going from larger screen to smaller HiDPI screen; sometimes in both dimensions, sometimes only horizontally. Also I think about:newtab has a separate failure mode where the rendering appears to be cached, so that it appears cropped even if you open a new tab on the smaller screen (if you'd opened it on the large screen before).
If someone with an affected system could give mozregression a try for hunting this down, it would be most helpful (sorry, I can only test on Windows and Linux).
As mentioned in comment 12, I don't think this is a regression, or the regression is very old (like 1-1.5 years).
I'm going to clear the regressionwindow-wanted flag then to get it off that radar, thanks.
Keywords: regressionwindow-wanted
Update: I see the problem described above in comment 1 on 43.0a2. I no longer see the problem in 44.0a1.
Flags: needinfo?(bwalker)
I still see this problem with 45.0a1 (2015-11-01).
Still having trouble with 47.0a1 (2016-02-14). How can we make progress on this issue?
This appears to be fixed for me in 48.0a1 (2016-03-22).
Interesting, I'm not aware of anything that landed in the last couple of days that would have fixed this. It might be good to get a fix window using mozregression so that we can uplift the fix and/or make sure it doesn't get backed out for whatever reason. Closing as WFM for now.
Last Resolved: 3 years ago
Flags: needinfo?(davidp99)
Resolution: --- → WORKSFORME
I actually tried a small mozregression run with the 2016-02-16 build, but couldn't reproduce it there. :( So wondering if it was somehow due to add-ons, but since I only have multi-DPI at work, I can't spend a lot of time on digging into this further, sorry.
You need to log in before you can comment on or make changes to this bug.