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

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[:Harald Kirschner :digitarald]

Attachment: 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

[:Harald Kirschner :digitarald]

+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

[:Harald Kirschner :digitarald]

Maybe related to bug 1125325.

I tested with e10s is disabled.

Comment 3

[:Harald Kirschner :digitarald]

This probably regressed a few weeks (2-3) back now, sorry to be not more specific.

Comment 4

[Daniel Holbert [:dholbert]]

: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...)

Comment 5

[Kartikaya Gupta (email:[e-mail])]

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)?

Comment 6

[:Harald Kirschner :digitarald]

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.

Comment 7

[:Harald Kirschner :digitarald]

Oh no, a similar effect just happened with APZ off when I disconnected my screen: https://cloudup.com/cWhtnZ1CKOy

Comment 8

[:Harald Kirschner :digitarald]

The last screenshot didn't make it: https://cloudup.com/iN8jW8unXyw

Comment 9

[Josh Carpenter [:jcarpenter]]

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.

Comment 10

[Daniel Holbert [:dholbert]]

[restoring needinfo from comment 4, accidentally cleared in comment 9]

Comment 11

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 12

[Dirkjan Ochtman (:djc)]

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).

Comment 13

[Dirkjan Ochtman (:djc)]

Ping?

Comment 14

[Ryan VanderMeulen [:RyanVM]]

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).

Comment 15

[Dirkjan Ochtman (:djc)]

As mentioned in comment 12, I don't think this is a regression, or the regression is very old (like 1-1.5 years).

Comment 16

[Ryan VanderMeulen [:RyanVM]]

I'm going to clear the regressionwindow-wanted flag then to get it off that radar, thanks.

Comment 17

[Bill Walker [:bwalker] [@wfwalker]]

Update: I see the problem described above in comment 1 on 43.0a2. I no longer see the problem in 44.0a1.

Comment 18

[Dirkjan Ochtman (:djc)]

I still see this problem with 45.0a1 (2015-11-01).

Comment 19

[Dirkjan Ochtman (:djc)]

Still having trouble with 47.0a1 (2016-02-14). How can we make progress on this issue?

Comment 20

[Dirkjan Ochtman (:djc)]

This appears to be fixed for me in 48.0a1 (2016-03-22).

Comment 21

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 22

[Dirkjan Ochtman (:djc)]

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.