Popup windows are opened in wrong positions and with wrong dimensions

VERIFIED FIXED in mozilla47

Status

()

Core
Widget: Gtk
--
blocker
VERIFIED FIXED
2 years ago
a year ago

People

(Reporter: marco, Assigned: jfkthame)

Tracking

({regression})

46 Branch
mozilla47
All
Linux
regression
Points:
---

Firefox Tracking Flags

(firefox45 unaffected, firefox46 unaffected)

Details

Attachments

(5 attachments)

(Reporter)

Description

2 years ago
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: → bug 1022241
(Reporter)

Comment 1

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

I suppose bug 890156 is at fault.
Thanks.
Blocks: 890156
Flags: needinfo?(jfkthame)
(Assignee)

Comment 3

2 years ago
Yes, I'm sure this'll be a regression from 890156, sorry. I'll try to reproduce and look into it.
Flags: needinfo?(jfkthame)
(Assignee)

Comment 4

2 years ago
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)
(Reporter)

Comment 5

2 years ago
No, it's the default value.

My screen resolution is 2880x1620.
Flags: needinfo?(mcastelluccio)
(Assignee)

Comment 6

2 years ago
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?
(Reporter)

Comment 7

2 years ago
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`
Created attachment 8708472 [details]
Site info doorhanger
Created attachment 8708473 [details]
Main menu
Created attachment 8708474 [details]
Context menu
Created attachment 8708475 [details]
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.
(Assignee)

Comment 14

2 years ago
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
status-firefox45: --- → unaffected
Keywords: regression
(Assignee)

Comment 16

2 years ago
(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)?
(Reporter)

Comment 17

2 years ago
(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 :)
(Assignee)

Updated

2 years ago
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
(Assignee)

Comment 21

2 years ago
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.
Attachment #8708998 - Flags: review?(VYV03354)
(Assignee)

Updated

2 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
(Assignee)

Comment 22

2 years ago
: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.
(Reporter)

Comment 23

2 years ago
> :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.
(Assignee)

Comment 26

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

Comment 27

2 years ago
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

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/f4bd1fc36f91
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox46: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Confirmed fixed in the latest Nightly.
Status: RESOLVED → VERIFIED
(Reporter)

Updated

2 years ago
See Also: → bug 1240749
(Assignee)

Comment 30

2 years ago
Backed out of aurora-46, see bug 890156 comment 168. Bumping target milestone to 47.
status-firefox46: fixed → unaffected
Target Milestone: mozilla46 → mozilla47
(Reporter)

Comment 31

a year ago
Julien is still able to reproduce this bug.
(Reporter)

Comment 32

a year ago
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.