1239855 - Popup windows are opened in wrong positions and with wrong dimensions

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[Marco Castelluccio [:marco]]

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.

Comment 1

[Marco Castelluccio [:marco]]

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=98756a36223c1a2b51cd0368736b728429038caf&tochange=a9f9b36c1a2eec7626e6b749e46ab0a8bf3323e2

I suppose bug 890156 is at fault.

Comment 2

[Karl Tomlinson (:karlt)]

Thanks.

Comment 3

[Jonathan Kew [:jfkthame]]

Yes, I'm sure this'll be a regression from 890156, sorry. I'll try to reproduce and look into it.

Comment 4

[Jonathan Kew [: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?

Comment 5

[Marco Castelluccio [:marco]]

No, it's the default value.

My screen resolution is 2880x1620.

Comment 6

[Jonathan Kew [:jfkthame]]

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?

Comment 7

[Marco Castelluccio [:marco]]

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`

Comment 8

[Eitan Isaacson [:eeejay]]

Attachment: Site info doorhanger

Comment 9

[Eitan Isaacson [:eeejay]]

Attachment: Main menu

Comment 10

[Eitan Isaacson [:eeejay]]

Attachment: Context menu

Comment 11

[Eitan Isaacson [:eeejay]]

Attachment: Awesomebar

Comment 12

[Eitan Isaacson [:eeejay]]

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.

Comment 13

[Eitan Isaacson [:eeejay]]

Also, it looks like Nightly stopped using libnotify? The notifications are also missized XUL boxes.

Comment 14

[Jonathan Kew [:jfkthame]]

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.

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

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

Comment 16

[Jonathan Kew [:jfkthame]]

(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)?

Comment 17

[Marco Castelluccio [:marco]]

(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 :)

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 21

[Jonathan Kew [:jfkthame]]

Attachment: 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.

Comment 22

[Jonathan Kew [:jfkthame]]

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

Comment 23

[Marco Castelluccio [:marco]]

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

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Seems to work here, both in e10s and non-e10s (menus in chrome and <select>s in content, and contextmenus)

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

I wonder if BoundsUseDesktopPixels() ? GetDesktopToDeviceScale().scale : 1.0; is something where a helper method could make sense.

Comment 26

[Jonathan Kew [:jfkthame]]

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

Comment 27

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f4bd1fc36f919836ad9b8ee5cb8b89a16aa4968c
Bug 1239855 - Fix for widget positioning/sizing on hidpi displays under Gtk. r=emk

Comment 28

[Carsten Book [:Tomcat]]

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

Comment 29

[Valentin Gosu [:valentin] (he/him)]

Confirmed fixed in the latest Nightly.

Comment 30

[Jonathan Kew [:jfkthame]]

Backed out of aurora-46, see bug 890156 comment 168. Bumping target milestone to 47.

Comment 31

[Marco Castelluccio [:marco]]

Julien is still able to reproduce this bug.

Comment 32

[Marco Castelluccio [:marco]]

Actually, what he's seeing might be due to the switch between GTK2 and GTK3.