chrille_b Reporter
	Description • 12 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20121119042013

Steps to reproduce:

I've run FF 18+ on OS X 10.8.2 with 2 screens. One screen runs in HIDPI mode, the other runs on non HIDPI mode. If i've put the FF window to non HIDPI screen. When entering a url like 'mac' the suggestion box opens on the HIDPI screen.

The HIDPI screen is left of the non HIDPI screen. 
Notice this happens on FF versions 18(aurora)-20(nightly). 
This bug occurs also on forms (e.g. <select> with <option> tags).


Actual results:

The suggestion box pops up on the wrong screen (hidpi screen).
Look at the attached file from the hidpi screen.

It seems like FF thinks all screen are in hidpi mode and calculates the wrong relative position.


Expected results:

The suggestion box should be opened on the screen where the window is.

	chrille_b Reporter
	Comment 3 • 12 years ago

update: to reproduce this bug the non hidpi screen must be right of hidpi screen (primary screen). 
If non hidpi screen is left of hidpi screen (primary), boxes pop up on the expected position.

	Glen Mailer
	Comment 5 • 12 years ago

Confirming bug, I'm seeing this with the setup described on the current Aurora channel.

	Jonathan Kew [:jfkthame] Assignee
	Comment 6 • 12 years ago

WIP - patch to fix the position/size issues with various popup windows on a lo-dpi screen to the right of the Retina display.

	Jonathan Kew [:jfkthame] Assignee
	Comment 7 • 12 years ago

There's a test build with this patch at:

http://ftp-scl3.mozilla.com/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-adce2f5c6899/try-macosx64/firefox-20.0a1.en-US.mac.dmg

chrille_b, Glen: if you're able to test this and confirm whether it resolves the problems you're seeing, that would be great. The patch wants some more tidying up before it's ready for review/landing, but I believe it should address the basic issue.

	chrille_b Reporter
	Comment 8 • 12 years ago

I can confirm that your test build resolves the problems of this bug. Thank you for fixing this bug.

	Glen Mailer
	Comment 10 • 12 years ago

I can also confirm that the patch above resolves the issue.

	Glen Mailer
	Comment 11 • 12 years ago

Sorry, I'll have to contradict myself now.

I'm still seeing some issues with some of the overlays, sometimes form autocomplete suggestions are clipped to a single item, and the search box suggestions list also seems to render with a box only tall enough to display the top item.

	Jonathan Kew [:jfkthame] Assignee
	Comment 12 • 12 years ago

Could you attach screenshots, and give specific steps to reliably reproduce those problems? Thanks.

	Glen Mailer
	Comment 13 • 12 years ago

Hopefully this isn't just me, I'm not sure if all of these steps are required, but they seem to work for me. The clipped overlay appears on either screen.

Cmd+N (new window)
Visit https://developer.mozilla.org/en-US/
Focus search box in UI
Press down
Overlay renders correctly
Focus search box in website
Press down
Overlay renders correctly
Enter a term in the search box which isn't already in the list
Press enter (submitting the search)
Focus the search box in the website
Clear the contents of the search box
Press down
*Overlay is clipped*
Focus the search box in the UI
Press down
*Overlay is clipped*

	Jonathan Kew [:jfkthame] Assignee
	Comment 15 • 12 years ago

The problem with the positioning of various kinds of "pop-up" windows arises because the Move and Resize methods for the window (implemented in nsCocoaWindow) take coordinates in device pixels. This is a problem in the specific case where there's a lo-dpi screen to the right of a hi-dpi one, because in this situation, the coordinate spaces of the two screens will "overlap" (because of the different scaling they use) - e.g. the MacBook's built-in Retina screen has x-coordinates from 0 to 2880 (in "retina device pixel" that are twice what the "cocoa points" would be), while the external display has x-coordinates that start at 1440 (because they're in lo-dpi  device pixels that correspond directly to cocoa points).

As a result, when code tries to place a popup window 500px from the left of the external display, for example, this is passed as a device-pixel coordinate of 1940 ... but that is also a device-pixel coordinate within the internal retina screen, and that's where the window ends up. :(

In the initial hidpi bugs, we fixed this for window creation, so that when we persist and restore window positions they reappear in the right place, but we need to do the same for the methods that move windows around on the (global) desktop space, as screen-specific device pixels may not give us a unified, consistent coordinate space for this.

	Jonathan Kew [:jfkthame] Assignee
	Comment 16 • 12 years ago

This switches us to use display pixels for window move/resize operations, to avoid the ambiguities of device pixels. It should make no difference on non-Mac systems where there's no distinction between display and device pixels. Tryserver job at https://tbpl.mozilla.org/?tree=Try&rev=17faea330af6.

	Jonathan Kew [:jfkthame] Assignee
	Comment 17 • 12 years ago

Glen, could you please check whether the problem described in comment 13 is still reproducible with the latest tryserver build? (http://ftp-scl3.mozilla.com/pub/mozilla.org/firefox/try-builds/jkew@mozilla.com-17faea330af6/try-macosx64/) Thanks!

	Steven Michaud [:smichaud] (Retired)
	Comment 18 • 12 years ago

Comment on attachment 689123 [details] [diff] [review]
use global display pixels for window positioning/sizing for consistency across mixed-resolution screens

Looks fine to me.  (I haven't tested it, though.)

Good catch!

	Jonathan Kew [:jfkthame] Assignee
	Comment 19 • 12 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/ac48e5c365e2

	chrille_b Reporter
	Comment 20 • 12 years ago

Sorry, I can't commit that Glens issue is fixed. This issue is fixed for me, that the suggestion box pops up on wrong screen (now it is displayed on the correct screen!). But the suggestion box for forms, that Glen reported isn't fixed. As far I can see or as far I'm able to reproduce Glens problem, this isn't fixed. 

The suggestion box on forms is not large enough. It displays only one row. It should display five or seven rows (I don't know). Sometimes the suggestion box does not appear or is only one row large.

Also the same occurs sometimes on the URL/address suggestion box, but I can't reproduce it now.

	chrille_b Reporter
	Comment 21 • 12 years ago

May be Glen should create a new bug, because this is a new or another issue ... and this can occur (really ???) also on a single screen configuration.

	Jonathan Kew [:jfkthame] Assignee
	Comment 22 • 12 years ago

Yes, please file that as a separate issue; I don't think it is directly related to the positioning problem here.

(I suspect it may be another manifestation of the issue that was filed but then closed in bug 816986. But until we have a clearer understanding, that's only a guess.)

	Ed Morley [:emorley]
	Comment 23 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/ac48e5c365e2

	Glen Mailer
	Comment 24 • 12 years ago

I'm not quite sure this can be marked as resolved, although I'll hold off reopening for now, in my use it feels like a few overlay-related bugs have been introduced, but these may not necessarily be directly related.

Can you confirm which nightly this landed in so I can try out the day before's to reproduce the other overlay issues as reported above?

In general use today on the build linked above i've been seeing a number of quirks with the overlays - including a clipped tooltip, and the awesomebar not showing any suggestions at all.

I'll try and get some proper reproducible scenarios when I can.

	Jonathan Kew [:jfkthame] Assignee
	Comment 25 • 12 years ago

The patch here has just merged to mozilla-central today, so the first Nightly build with it will be tomorrow's (2012-12-08).

Unless you still see the specific problem originally described here - the URL suggestions or other "popup" windows being displayed on the wrong screen when using multiple displays - please file separate reports for any remaining/new issues. That helps greatly with keeping track.

(If there are new problems that appear to be introduced by this fix, you could mark them as blocking this bug; otherwise, if they're specific to HiDPI systems but not specifically related to this change, mark them as blocking bug 785330, the general HiDPI-support tracker. But only reopen -this- bug if its specific issue is not actually fixed. Thanks a bunch!)

	Jonathan Kew [:jfkthame] Assignee
	Comment 26 • 12 years ago

FTR, the problem of drop-downs (sometimes?) only showing a single item has been filed as bug 820327. Any further input/discussion/suggestions there would be appreciated, as I can't currently reproduce the problem myself for investigation.

	Jet Villegas (inactive)
	Comment 28 • 11 years ago

tracking19:?

Release Drivers: we're getting multiple reports from FF18 users about this bug (and dependent bugs) now fixed in FF20. Please consider taking an uplift to FF19.

	Jonathan Kew [:jfkthame] Assignee
	Comment 29 • 11 years ago

Rollup patch for beta of this bug plus its dependencies (819725, 821454, 821679, 822307). The changesets all transplanted cleanly from current Aurora to Beta trees.

	Jonathan Kew [:jfkthame] Assignee
	Comment 30 • 11 years ago

Comment on attachment 701446 [details] [diff] [review]
rollup for mozilla-beta

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 794038

User impact if declined:
Rendering/usability glitches (especially with drop-down/popup menus) on retina Mac systems with multiple monitors; see also descriptions in bug 828514.

Testing completed (on m-c, etc.):
On Nightly for several weeks, now also on Aurora.

Risk to taking this patch (and alternatives if risky):
The initial patch here carried significant risk (which is why we didn't immediately seek to uplift it); and sure enough, we had regressions on Windows regarding context menus (bug 819725), plugins (bug 821454) and tab thumbnails (bug 821679). These are all fixed on Nightly/Aurora, and I now believe the complete set of patches is tested and stable enough that we should take them for FF19 so as to get this fix out to affected users.

An alternative would be to disable HiDPI support on multi-monitor configurations (effectively reverting to FF17 behavior, where users with an external display get scaled low-DPI (fuzzy) rendering. We could do this with a trivial pref change (set gfx.hidpi.enabled=1 as default), but losing Retina-quality rendering altogether on such systems would also be a poor user experience.

String or UUID changes made by this patch: None.

	Alex Keybl [:akeybl]
	Comment 31 • 11 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #30)
> An alternative would be to disable HiDPI support on multi-monitor
> configurations (effectively reverting to FF17 behavior, where users with an
> external display get scaled low-DPI (fuzzy) rendering. We could do this with
> a trivial pref change (set gfx.hidpi.enabled=1 as default), but losing
> Retina-quality rendering altogether on such systems would also be a poor
> user experience.

The risk of regression for non-Mac non-HiDPI non-multi-monitor (>99.9% of our users) is much too large to take this amount of code change on Beta. This needs more bake time. Your alternative solution is a much better solution, and one that we may want to consider for an 18.0.1. Can you prepare this trivial patch for Monday?

We'll make sure to release note the behavior.

	Jonathan Kew [:jfkthame] Assignee
	Comment 32 • 11 years ago

This pref change will disable HiDPI support when there are mixed hi- and lo-dpi screens. (Note that users who dynamically change their display configuration while Firefox is open - e.g. by attaching an external monitor to a retina macbook - will need to quit and restart the browser, otherwise they'll still be liable to experience problems, as we can't dynamically turn off HiDPI in an already-existing window.)

	Jonathan Kew [:jfkthame] Assignee
	Comment 33 • 11 years ago

(In reply to Alex Keybl [:akeybl] from comment #31)
> (In reply to Jonathan Kew (:jfkthame) from comment #30)
> > An alternative would be to disable HiDPI support on multi-monitor
> > configurations (effectively reverting to FF17 behavior, where users with an
> > external display get scaled low-DPI (fuzzy) rendering. We could do this with
> > a trivial pref change (set gfx.hidpi.enabled=1 as default), but losing
> > Retina-quality rendering altogether on such systems would also be a poor
> > user experience.
> 
> The risk of regression for non-Mac non-HiDPI non-multi-monitor (>99.9% of
> our users) is much too large to take this amount of code change on Beta.
> This needs more bake time. Your alternative solution is a much better
> solution, and one that we may want to consider for an 18.0.1. Can you
> prepare this trivial patch for Monday?

Patch posted, see above. If there's going to be an 18.0.1, I agree that we should consider backing off the HiDPI pref to 1, so as to avoid the multi-screen issues (modulo the dynamic-changes issue noted above).

Might you reconsider uplifting the "real" fix to 19 after it's had a couple more weeks bake time on Aurora, or would it be pointless to request that?

	Alex Keybl [:akeybl]
	Comment 34 • 11 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #33)
> Patch posted, see above. If there's going to be an 18.0.1, I agree that we
> should consider backing off the HiDPI pref to 1, so as to avoid the
> multi-screen issues (modulo the dynamic-changes issue noted above).
> 
> Might you reconsider uplifting the "real" fix to 19 after it's had a couple
> more weeks bake time on Aurora, or would it be pointless to request that?

Seems too risky to take for FF19. Does attachment 701603 [details] [diff] [review] need review for uplift to 19 (and possible 18)?

	Jonathan Kew [:jfkthame] Assignee
	Comment 35 • 11 years ago

Comment on attachment 701603 [details] [diff] [review]
pref off hidpi support for multi-display configurations

Steven: see preceding comments; this is intended for FF19 and possibly 18, not for trunk or aurora.

	Alex Keybl [:akeybl]
	Comment 36 • 11 years ago

Comment on attachment 701603 [details] [diff] [review]
pref off hidpi support for multi-display configurations

Approving for Beta given our desire to uplift to FF18.0.1, and the fact that this fix has been deemed trivial. Also adding qawanted/verifyme so that QA makes sure to double check this behavior.

Jonathan - given the fact that this will be released mostly blindly, please help with testing as well (perhaps through a try build).

	Jonathan Kew [:jfkthame] Assignee
	Comment 37 • 11 years ago

Pushed to mozilla-beta:
https://hg.mozilla.org/releases/mozilla-beta/rev/cb8fa413605f

Tryserver job in progress (not expecting any test issues there, as tryserver doesn't test HiDPI systems anyway, but this should provide a build that QA can use):
https://tbpl.mozilla.org/?tree=Try&rev=8c189a16f563

	bhavana bajaj [:bajaj]
	Comment 38 • 11 years ago

(In reply to Jonathan Kew (:jfkthame) from comment #37)
> Pushed to mozilla-beta:
> https://hg.mozilla.org/releases/mozilla-beta/rev/cb8fa413605f
> 
> Tryserver job in progress (not expecting any test issues there, as tryserver
> doesn't test HiDPI systems anyway, but this should provide a build that QA
> can use):
> https://tbpl.mozilla.org/?tree=Try&rev=8c189a16f563

Can you please help nominate the patch for approval-mozilla-release in preparation to get this ready for a possible 18.0.1 ? Thanks

	Jonathan Kew [:jfkthame] Assignee
	Comment 39 • 11 years ago

Comment on attachment 701603 [details] [diff] [review]
pref off hidpi support for multi-display configurations

[Approval Request Comment]
Regression caused by (bug #): 794038

User impact if declined:
Rendering/usability glitches (especially with drop-down/popup menus) on retina Mac systems with multiple monitors; see also descriptions in bug 828514.

Testing completed (on m-c, etc.):
Patch itself is minimally tested, but trivial. Affected users have confirmed that disabling HiDPI support resolves the issues; this patch just changes the default value of the HiDPI pref.

Risk to taking this patch (and alternatives if risky):
This pref-change -will- "regress" behavior in the sense that Retina MacBook users with external displays will no longer get HiDPI rendering on the Retina display (until FF20, when the main patch here and its dependencies ship). This is unfortunate, but overall it's still a better experience than the problems with "popup" elements like the awesomebar suggestions appearing incorrectly across multiple displays.

	bhavana bajaj [:bajaj]
	Comment 40 • 11 years ago

Comment on attachment 701603 [details] [diff] [review]
pref off hidpi support for multi-display configurations

Please go ahead and land the patch on mozilla-release .

	Jonathan Kew [:jfkthame] Assignee
	Comment 41 • 11 years ago

https://hg.mozilla.org/releases/mozilla-release/rev/69cc79a6a535

	Jonathan Kew [:jfkthame] Assignee
	Comment 42 • 11 years ago

Oops, my bad - that was pushed with a=akeybl instead of a=bajaj in the commit message.

	Ioana (away)
	Comment 44 • 11 years ago

chrille_b, can you please verify that this issue doesn't reproduce on Firefox 18.0.1 and 19 beta 2?

	chrille_b Reporter
	Comment 45 • 11 years ago

This bug is not reproduceable on Firefox 19b2 downloaded from here http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/19.0b2/mac/en-US/Firefox%2019.0b2.dmg

I cannot say if it is reproduceable on 18.0.1 because I don't know where to download it.

	Matt Wobensmith [:mwobensmith][:matt:]
	Comment 46 • 11 years ago

As per steps above, I verified URL suggestion box, Google search field, forms, select/option menus. In affected build, all were drawn on the Retina display, but drawn correctly in 19.0b2.

Also verified the pref change for gfx.hidpi.enabled, which makes the above possible.

Confirmed issue present in 19.0b1, fixed in 19.0b2.

	u279076
	Comment 47 • 11 years ago

Thanks Matt, can you please confirm:
* Firefox 19.0b2 pref("gfx.hidpi.enabled", 1); and this bug does not exist
* Firefox 20.0a2 pref("gfx.hidpi.enabled", 2); and this bug does not exist

Thanks

	Matt Wobensmith [:mwobensmith][:matt:]
	Comment 48 • 11 years ago

Pref in 19.0b2 is set to 1, and issue does not exist.
Pref in 20.0a2 is set to 2, and issue does not exist.

Additionally, pref is set to 1 in 18.0 2013-01-16, and issue does not exist there as well, though it does exist in currently shipping 18.

	u279076
	Comment 49 • 11 years ago

Excellent! Thank you Matt.

	Sendu Bala
	Comment 50 • 11 years ago

This is not really fixed. See bug 832591.

	Andrew Curtin
	Comment 51 • 11 years ago

this is a terrible fix. Sure, it fixed the pop ins (and intermittent issue), but it completely disabled retina support, and makes firefox look like garbage (IMO it's unusable) all the time (a constant issue).

	Alex Keybl [:akeybl]
	Comment 52 • 11 years ago

(In reply to Sendu Bala from comment #50)
> This is not really fixed. See bug 832591.

It will be fully fixed as of FF20, released the first week of April. For now, the behavior in 18.0.1 for multi-monitor setups will remain until the final fix has had more bake time with pre-release audiences.