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.
+2 of my colleagues next to me have the same behavior. It is also reproducible when connecting to Airplay in the meeting rooms.
Maybe related to bug 1125325. I tested with e10s is disabled.
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
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
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)?
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.
Oh no, a similar effect just happened with APZ off when I disconnected my screen: https://cloudup.com/cWhtnZ1CKOy
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.
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.
Update: I see the problem described above in comment 1 on 43.0a2. I no longer see the problem in 44.0a1.
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
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.