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.

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?

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

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.

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

This _might_ have been fixed by bug 978913.

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

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

(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/

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

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.

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