948090 - Multi-process mode zooms content when changing display density

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P1)

Description

[Steven L]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131209053402

Steps to reproduce:

Prerequisites (others may work, this is my setup)
* Retina MacBook Pro
* Non-retina external display

1) Enable process-per-tab mode in about:config via "browser.tabs.remote" => set to true.  This bug DOES NOT appear when remote is set to false.
2) Attach a second monitor with a different display density
3) Launch Firefox
4) Drag Firefox to the other display


Actual results:

Going from high-DPI to low-DPI causes the website-portion of the Firefox window to double in size, at least superficially the same as if you zoomed to 200%.

Going from low-DPI to high-DPI does the reverse, zooming it out.

This happens on all webpages.


Expected results:

Display should appear the same, scaling to match the new density.

Comment 1

[Steven L]

Attachment: launched on high density screen

Comment 2

[Steven L]

Attachment: dragged to low density screen

Comment 3

[Petruta Horea [:phorea], Desktop QA]

Not having the required hardware to reproduce this. On Win 7 with two displayed it is not reproducible.

Could someone else please try and confirm it?

Comment 4

[u279076]

Marc, can you please see if you can reproduce this?

Comment 5

[Marc Schifer [mschifer]]

Veriifed this on my Macbook Pro  (10.8.5) with retinia display and an external Dell monitor.  Dragging a browswer instance between the two screen causes the browser to "zoom" in and out as described.

Comment 6

[Chris Peterson [:cpeterson]]

Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".

Comment 7

[Mike Conley (:mconley) (:⚙️)]

This _might_ have been fixed by bug 978913.

Comment 8

[David Parks [:handyman]]

I believe Mike is right.  This is working on my MBP w/ external low-dpi monitor.

Comment 9

[Steven L]

Seems to have returned, exact same behavior, in 41.0a1 (2015-06-03).

Comment 10

[u279076]

(In reply to Steven L from comment #9)
> Seems to have returned, exact same behavior, in 41.0a1 (2015-06-03).

Was this working as expected in a recent Nightly? If so, could you use mozgression to narrow this down? http://mozilla.github.io/mozregression/

Comment 11

[Steven L]

I haven't noticed it in previous versions (I use the nightly build every day), though I could have just missed it for around a week or so.

I'll give mozregression a try when I'm plugged back into the monitor tomorrow, thanks for the link :)

Comment 12

[Steven L]

d'oh.  After trying to cause this to happen a ton of times, I realized this is in fact a different behavior.  It only zooms when I grab a tab and drag it to the secondary display.  I'd be happy to open up a new bug report if that's the right thing to do here :)

Unfortunately, trying to mozregression the tab bug has been quite painful.  An huge number of builds don't retain tab contents when it's pulled out to a new window, so I'm forced to 'skip' those, which eventually leads to me testing something like 50 builds :|  Of the few builds that _do_ retain contents, at the very least the bug exists at 2014-10-22, and still exists today.

Comment 13

[u279076]

(In reply to Steven L from comment #12)
> d'oh.  After trying to cause this to happen a ton of times, I realized this
> is in fact a different behavior.  It only zooms when I grab a tab and drag
> it to the secondary display.  I'd be happy to open up a new bug report if
> that's the right thing to do here :)

Yes please open a new bug report describing this behaviour, including steps to reproduce and any information about your test environment (monitor configurations for example).

> Unfortunately, trying to mozregression the tab bug has been quite painful. 
> An huge number of builds don't retain tab contents when it's pulled out to a
> new window, so I'm forced to 'skip' those, which eventually leads to me
> testing something like 50 builds :|  Of the few builds that _do_ retain
> contents, at the very least the bug exists at 2014-10-22, and still exists
> today.

That's unfortunate but it just means you'll need to try to narrow down the range manually. Once you get a new bug filed I can help you with that process.