[hidpi/retina] url suggestion box pops up on wrong screen

VERIFIED FIXED in Firefox 20

Status

()

Core
Widget: Cocoa
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: chrille_b, Assigned: jfkthame)

Tracking

(Blocks: 1 bug, {relnote})

18 Branch
mozilla20
x86
Mac OS X
relnote
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18- verified disabled, firefox19- verified disabled, firefox20 verified)

Details

Attachments

(7 attachments, 1 obsolete attachment)

(Reporter)

Description

5 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.
(Reporter)

Comment 1

5 years ago
Created attachment 684433 [details]
hidpi screenshot
(Reporter)

Comment 2

5 years ago
Created attachment 684434 [details]
non-hidpi screen screenshot
Component: Untriaged → Widget: Cocoa
Product: Firefox → Core
(Reporter)

Comment 3

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

Updated

5 years ago
Duplicate of this bug: 813962

Comment 5

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

Updated

5 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

5 years ago
Blocks: 785330
(Assignee)

Comment 6

5 years ago
Created attachment 687273 [details] [diff] [review]
always use global display pixels for popup window positioning/sizing

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

Comment 7

5 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.
Assignee: nobody → jfkthame
(Reporter)

Comment 8

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

Updated

5 years ago
Duplicate of this bug: 817132

Comment 10

5 years ago
I can also confirm that the patch above resolves the issue.

Comment 11

5 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.
(Assignee)

Comment 12

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

Comment 13

5 years ago
Created attachment 687810 [details]
Screenshot of clipped overlay

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*

Comment 14

5 years ago
Created attachment 687811 [details]
Screenshot of clipped overlay inside page
(Assignee)

Comment 15

4 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.
(Assignee)

Comment 16

4 years ago
Created attachment 689123 [details] [diff] [review]
use global display pixels for window positioning/sizing for consistency across mixed-resolution screens

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.
Attachment #689123 - Flags: review?(smichaud)
(Assignee)

Updated

4 years ago
Attachment #687273 - Attachment is obsolete: true
(Assignee)

Comment 17

4 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!
(Assignee)

Updated

4 years ago
Blocks: 794038
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!
Attachment #689123 - Flags: review?(smichaud) → review+
(Assignee)

Comment 19

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ac48e5c365e2
Target Milestone: --- → mozilla20
(Reporter)

Comment 20

4 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.
(Reporter)

Comment 21

4 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.
(Assignee)

Comment 22

4 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.)
https://hg.mozilla.org/mozilla-central/rev/ac48e5c365e2
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 24

4 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.
(Assignee)

Comment 25

4 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!)
(Assignee)

Updated

4 years ago
Depends on: 819725
(Assignee)

Comment 26

4 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.
(Assignee)

Updated

4 years ago
Duplicate of this bug: 826402

Comment 28

4 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.
status-firefox19: --- → affected
tracking-firefox19: --- → ?
(Assignee)

Comment 29

4 years ago
Created attachment 701446 [details] [diff] [review]
rollup for mozilla-beta

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

Comment 30

4 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.
Attachment #701446 - Flags: approval-mozilla-beta?
(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.
tracking-firefox18: --- → ?
tracking-firefox19: ? → +
Keywords: relnote

Updated

4 years ago
Attachment #701446 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
(Assignee)

Comment 32

4 years ago
Created attachment 701603 [details] [diff] [review]
pref off hidpi support for multi-display configurations

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

Comment 33

4 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?
(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)?
tracking-firefox18: ? → +
(Assignee)

Comment 35

4 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.
Attachment #701603 - Flags: review?(smichaud)
Attachment #701603 - Flags: review?(smichaud) → review+
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).
Attachment #701603 - Flags: approval-mozilla-beta+

Updated

4 years ago
Keywords: qawanted, verifyme
QA Contact: jbecerra
(Assignee)

Comment 37

4 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
(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
status-firefox19: affected → disabled
status-firefox20: --- → fixed
(Assignee)

Comment 39

4 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.
Attachment #701603 - Flags: approval-mozilla-release?
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 .
Attachment #701603 - Flags: approval-mozilla-release? → approval-mozilla-release+
(Assignee)

Comment 41

4 years ago
https://hg.mozilla.org/releases/mozilla-release/rev/69cc79a6a535
(Assignee)

Comment 42

4 years ago
Oops, my bad - that was pushed with a=akeybl instead of a=bajaj in the commit message.
Duplicate of this bug: 831017

Comment 44

4 years ago
chrille_b, can you please verify that this issue doesn't reproduce on Firefox 18.0.1 and 19 beta 2?
(Reporter)

Comment 45

4 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.
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.
Keywords: qawanted, verifyme
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
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.
Status: RESOLVED → VERIFIED
status-firefox18: --- → verified disabled
status-firefox19: disabled → verified disabled
status-firefox20: fixed → verified
Excellent! Thank you Matt.

Comment 50

4 years ago
This is not really fixed. See bug 832591.

Comment 51

4 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).
(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.
tracking-firefox18: + → -
tracking-firefox19: + → -
Duplicate of this bug: 828148
(Assignee)

Updated

4 years ago
Depends on: 840881

Updated

4 years ago
Depends on: 858442
You need to log in before you can comment on or make changes to this bug.