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

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
3 years ago
2 years ago

People

(Reporter: Harald, Unassigned)

Tracking

({regression})

Trunk
Unspecified
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(firefox43 affected)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

(Reporter)

Description

3 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.
(Reporter)

Comment 1

3 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.
(Reporter)

Comment 2

3 years ago
Maybe related to bug 1125325.

I tested with e10s is disabled.
(Reporter)

Comment 3

3 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1189565. Can you check if it still happens with layers.async-pan-zoom.enabled set to false (requires restart)?

Updated

3 years ago
Whiteboard: [gfx-noted]
(Reporter)

Comment 6

3 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)
(Reporter)

Comment 7

3 years ago
Oh no, a similar effect just happened with APZ off when I disconnected my screen: https://cloudup.com/cWhtnZ1CKOy
(Reporter)

Comment 8

3 years ago
The last screenshot didn't make it: https://cloudup.com/iN8jW8unXyw
May be related to issues that have cropped up with WebVR video playback, as captured here: https://bugzilla.mozilla.org/show_bug.cgi?id=1196412

Currently video textures appear to be misaligned when viewing content in VR mode. Testing requires Firefox Nightly + WebVR Add-on (later available from http://mozvr.com/downloads/).

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).
Ping?
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.
Status: NEW → RESOLVED
Last Resolved: 2 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.