Closed Bug 1239855 Opened 4 years ago Closed 4 years ago

Popup windows are opened in wrong positions and with wrong dimensions

Categories

(Core :: Widget: Gtk, defect, blocker)

46 Branch
All
Linux
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
mozilla47
Tracking Status
firefox45 --- unaffected
firefox46 --- unaffected

People

(Reporter: marco, Assigned: jfkthame)

References

Details

(Keywords: regression)

Attachments

(5 files)

Any popup window (by popup window I mean, for example, the awesome bar suggestions, or the Australis menu, or the right-click menu) is opening in a wrong position and sometimes with wrong dimensions.
This is a recent regression, since this morning everything was working just fine.
See Also: → 1022241
Thanks.
Blocks: 890156
Flags: needinfo?(jfkthame)
Yes, I'm sure this'll be a regression from 890156, sorry. I'll try to reproduce and look into it.
Flags: needinfo?(jfkthame)
Do you have layout.css.devPixelsPerPx set to a non-default value in about:config?

If you reset it to the default (-1.0), do you still see this problem?
Flags: needinfo?(mcastelluccio)
No, it's the default value.

My screen resolution is 2880x1620.
Flags: needinfo?(mcastelluccio)
OK. thanks. So far, I haven't managed to reproduce this except by setting a custom devPixelsPerPx. But that doesn't apply in your case, so there's something more going on....  What distro and desktop manager are you running, and how is the display DPI configured?
Ubuntu 15.04, the window manager is the default one (Compiz).

In the settings, I've set scaling to 1,5.

`xrdb -query | grep dpi` tells me `Xft.dpi 144`
Attached image Main menu
Attached image Context menu
Attached image Awesomebar
Attached are a few places where I see it. It makes Nightly pretty unusable.
I'm on Fedora 23, xrdb reports my DPI to be 192. devPixelsPerPx is -1.
Also, it looks like Nightly stopped using libnotify? The notifications are also missized XUL boxes.
OK, I can reproduce this; it seems that it happens if your desktop scaling factor is set to at least 1.5 (testing at lower values like 1.25 or 1.38, I don't see the problem happening).

So a workaround for now, until we get it fixed, would be to reduce your scaling factor below 1.5, though obviously that's going to affect everything on the system -- so depending on your specific situation, it may not really be feasible.
I use layout.css.dpi 1.4 and run into this issue. Using a lower value makes things too small to comfortably read the solution for me is to downgrade to the build before bug 890156 landed. https://ftp.mozilla.org/pub/firefox/nightly/2016/01/2016-01-12-03-02-27-mozilla-central/firefox-46.0a1.en-US.linux-x86_64.tar.bz2
(In reply to Kevin Brosnan [:kbrosnan] from comment #15)
> I use layout.css.dpi 1.4 and run into this issue. Using a lower value makes
> things too small to comfortably read the solution for me is to downgrade to
> the build before bug 890156 landed.
> https://ftp.mozilla.org/pub/firefox/nightly/2016/01/2016-01-12-03-02-27-
> mozilla-central/firefox-46.0a1.en-US.linux-x86_64.tar.bz2

What version of Windows are you on? What scaling factor do you have in the Display control panel in Windows? What happens if you reset layout.css.devPixelsPerPx (I don't think you meant .dpi there) to its default of -1.0 (automatic)?
(In reply to Jonathan Kew (:jfkthame) from comment #16)
> (In reply to Kevin Brosnan [:kbrosnan] from comment #15)
> > I use layout.css.dpi 1.4 and run into this issue. Using a lower value makes
> > things too small to comfortably read the solution for me is to downgrade to
> > the build before bug 890156 landed.
> > https://ftp.mozilla.org/pub/firefox/nightly/2016/01/2016-01-12-03-02-27-
> > mozilla-central/firefox-46.0a1.en-US.linux-x86_64.tar.bz2
> 
> What version of Windows are you on? What scaling factor do you have in the
> Display control panel in Windows? What happens if you reset
> layout.css.devPixelsPerPx (I don't think you meant .dpi there) to its
> default of -1.0 (automatic)?

I think you commented on the wrong bug :)
Duplicate of this bug: 1240390
Duplicate of this bug: 1240402
If the fix will take couple of days, could we back out bug 890156? Nightly is now pretty much unusable on recent laptops running Linux.
Severity: normal → blocker
This is equivalent to some of the widget-management changes made for Windows in bug 890156, and appears to fix the brokenness under hidpi conditions on Linux. (I won't be greatly surprised if there are additional minor issues to clean up as we get more testing, but this should make a big difference to Nightly usability.) Try build in progress: https://treeherder.mozilla.org/#/jobs?repo=try&revision=39acff5ace44.
Attachment #8708998 - Flags: review?(VYV03354)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
:marco, :eeejay, :kbrosnan, :smaug -- if any of you care to try the above patch (either in a local build, or once the tryserver build is available) and confirm whether it fixes the problem on your configuration, that would be appreciated.
> :marco, :eeejay, :kbrosnan, :smaug -- if any of you care to try the above patch (either in a local build, or once the tryserver build is available) and confirm whether it fixes the problem on your configuration, that would be appreciated.

It fixes the problem for me.
Attachment #8708998 - Flags: review?(VYV03354) → review+
Seems to work here, both in e10s and non-e10s (menus in chrome and <select>s in content, and contextmenus)
I wonder if BoundsUseDesktopPixels() ? GetDesktopToDeviceScale().scale : 1.0; is something where a helper method could make sense.
(In reply to Olli Pettay [:smaug] from comment #25)
> I wonder if BoundsUseDesktopPixels() ? GetDesktopToDeviceScale().scale :
> 1.0; is something where a helper method could make sense.

Perhaps, but I'm inclined to defer that to a possible followup. Might be tricky to find a clear-yet-concise name for such a method. (Something like ScaleFactorForBoundsParameters()?)

An alternative (better?) option might be a more extensive redesign of the nsIWidget API, such that we'd pass position/size parameters using the appropriate strongly-typed Point/Size/Rect units instead of a bunch of typeless integers that we then need to know how to interpret within the Move/Resize method, depending on the kind of widget involved.

This would be sort of like the recent change to nsIWidget::Create, which now has two flavors to handle either LayoutDevice or Desktop pixels, where it used to take an nsIntRect that had varying meanings depending on the situation.
https://hg.mozilla.org/integration/mozilla-inbound/rev/f4bd1fc36f919836ad9b8ee5cb8b89a16aa4968c
Bug 1239855 - Fix for widget positioning/sizing on hidpi displays under Gtk. r=emk
https://hg.mozilla.org/mozilla-central/rev/f4bd1fc36f91
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Confirmed fixed in the latest Nightly.
Status: RESOLVED → VERIFIED
See Also: → 1240749
Backed out of aurora-46, see bug 890156 comment 168. Bumping target milestone to 47.
Target Milestone: mozilla46 → mozilla47
Julien is still able to reproduce this bug.
Actually, what he's seeing might be due to the switch between GTK2 and GTK3.
You need to log in before you can comment on or make changes to this bug.