977.65 KB, image/png
335.64 KB, image/png
1.02 MB, image/png
375.88 KB, image/png
4.44 KB, patch
|Details | Diff | Splinter Review|
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.
Yes, I'm sure this'll be a regression from 890156, sorry. I'll try to reproduce and look into it.
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?
No, it's the default value. My screen resolution is 2880x1620.
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 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 :)
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.
Created attachment 8708998 [details] [diff] [review] Fix for widget positioning/sizing on hidpi displays under Gtk 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.
: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.
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
Confirmed fixed in the latest Nightly.
Backed out of aurora-46, see bug 890156 comment 168. Bumping target milestone to 47.
Julien is still able to reproduce this bug.
Actually, what he's seeing might be due to the switch between GTK2 and GTK3.