User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/20100101 Firefox/18.0 Build ID: 20130116073211 Steps to reproduce: Started Firefox 18.0.1 on a rMBP (OS X 10.8.2) while an external monitor was plugged in. The browser window is entirely within the laptop screen. Actual results: HIDPI mode was disabled (ie. text was low resolution). Quiting Firefox, unplugging the external monitor, then starting Firefox restores HIDPI mode. Plugging the external monitor back in at this point retains HIDPI mode. Leaving the external monitor plugged in, quiting Firefox and restarting it loses HIDPI mode. At this point unplugging and reconnecting the external monitor makes no difference - HIDPI mode remains off. Expected results: HIDPI mode should have been enabled at all times when the browser window was on the laptop's screen.

I'll also note that bug 814434 isn't really fixed (and I'm guessing is the cause of this bug). If Firefox is started with no external monitor (so that HIDPI mode works), and then the external monitor is attached, and then the browser window is moved to the external screen, menus etc. appear on the laptop screen just as they used to in 18.0.0.

Disabling HiDPI support when an external monitor is present was the expected behavior for FF 18.0.1 (and 19 beta); e.g. see 814434 comment 39. This was done to avoid the problems with popup/menu display, etc, as described in that bug. If you want to re-enable HiDPI in that situation - understanding that the bug with popup display WILL reappear! - you can set gfx.hidpi.enabled to 2 in about:config. But because of the problems with that setup, we decided not to ship the product with that setting by default. Alternatively, you could try running the Aurora build (Firefox 20 pre-release). This should work much better when an external display is present.

Ah. You might want to correct http://www.mozilla.org/en-US/firefox/18.0.1/releasenotes/ so that it is less confusing. Eg. change it to "18.0.1: Disabled HIDPI support when external monitors are used to avoid rendering glitches".

I can't believe this is set to WONTFIX. Now Firefox won't render in HiDPI if I have an external monitor plugged in, regardless if Firefox is even on that monitor. I have to massage Firefox into going into retina mode by plugging in the monitor later? This is a good experience for users? How can you consider this a fix? Hopefully 'disabling retina' is not a 'feature' in 20.

(In reply to Derek Gates from comment #4) > I can't believe this is set to WONTFIX. > > Now Firefox won't render in HiDPI if I have an external monitor plugged in, > regardless if Firefox is even on that monitor. Correct. How can Firefox know whether you might suddenly decide to drag its window over to the other screen? Given that it can't handle that properly, the safer option is to disable HiDPI mode in this case. > > I have to massage Firefox into going into retina mode by plugging in the > monitor later? This is a good experience for users? Or you can set gfx.hidpi.enabled to 2 (in about:config), and then it'll always use retina mode on the internal display, even with the external monitor present. But if you do either of these things, and then move windows around between monitors, you'll run into more glaring problems - see bug 814434. Therefore, this has been switched off by default, so that naive users don't run into those issues. > > > How can you consider this a fix? Hopefully 'disabling retina' is not a > 'feature' in 20. As already stated, Firefox 20 includes better retina + multi-monitor support. If you're anxious to have this feature, I'd recommend running Aurora at this point. See http://www.mozilla.org/en-US/firefox/aurora/

Jonathan, I agree and apologize for my post. It was shocking to see Firefox revert back to pre-retina builds after all the work you have done to support HiDPI. I have enabled the gfx.hidpi.enabled:2 toggle and will be satisfied until the next BETA is released.

I wasn't happy either, but given bug 814434, this was our best option for the current release. Firefox 20 is on its way... it'll be on Beta in a month, if running Aurora seems too risky an option at the moment.

Not to pile on, but I agree that it's a bad/confusing experience for people with a retina screen and an external display. I was sitting here looking at fuzzy fonts on my retina screen and discovered I could use 2 for gfx.hidpi.enabled from https://support.mozilla.org/en-US/questions/947663#answer-399646 (which lead me to this bug). I restarted Firefox and like magic the fonts are beautiful on the retina screen. And when I drag the window to the external display it looks fine. It sounds like Jonathan did a bunch of work on retina support so thanks, Jonathan!

(In reply to Philip Durbin from comment #8) > Not to pile on, but I agree that it's a bad/confusing experience for people > with a retina screen and an external display. I was sitting here looking at > fuzzy fonts on my retina screen and discovered I could use 2 for > gfx.hidpi.enabled from > https://support.mozilla.org/en-US/questions/947663#answer-399646 (which lead > me to this bug). I restarted Firefox and like magic the fonts are beautiful > on the retina screen. And when I drag the window to the external display it > looks fine. Yes, but...if your external screen is configured to the right of the built-in display, and you try to use popup menus or the URL bar with the window on that screen, you'll probably see issues. If you're willing to live with those problems (e.g., by simply avoiding the particular scenarios involved), then by all means use gfx.hidpi.enabled=2 and enjoy it.

Hmm, I just did a quick test (usually I have my monitor above my laptop screen) and it still seems fine. Thanks again! :)

You would rather have the browser look like complete **** and have pop ins pop up in the right spot, as opposed to pop ins in the wrong spot and the browser looking good? One of these things affects usability 100% of the time. One does not. As it currently is, without modification, I would not use firefox, because it looks so bad. It seems like a no brainer which of the two issues should have priority. My opinion is that the fix for bug 814434 should be reverted until a proper fix is implemented.