Closed
Bug 1441665
Opened 6 years ago
Closed 6 years ago
[CSD] when Title Bar is disabled, page elements and popups are drawn in the wrong location
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
FIXED
mozilla61
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox58 | --- | unaffected |
firefox59 | - | disabled |
firefox60 | - | wontfix |
firefox61 | --- | fixed |
People
(Reporter: commander.commando, Assigned: stransky)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
Attachments
(2 files)
6.14 MB,
image/gif
|
Details | |
59 bytes,
text/x-review-board-request
|
jhorak
:
review+
ritu
:
approval-mozilla-beta-
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180227100126 Steps to reproduce: use right-click context menus or Select elements. Actual results: When Title Bar is disabled in Firefox (Nightly and Developer Edition on Linux), these elements are drawn in the wrong location. Expected results: The upper-right corner of context menus should align with the point of the cursor, and dropdown lists for select elements should align with the parent element.
Comment 1•6 years ago
|
||
it seems to need restart browser to reproduce the issue.
Status: UNCONFIRMED → NEW
Component: Untriaged → Widget: Gtk
Ever confirmed: true
OS: Unspecified → Linux
Product: Firefox → Core
Comment 2•6 years ago
|
||
I can reproduce the issue context menu and select element on Linux Mint.
status-firefox59:
--- → affected
status-firefox60:
--- → affected
Comment 4•6 years ago
|
||
[Tracking Requested - why for this release]: Context menu and select element misaligned when titlebar is disabled.
tracking-firefox59:
--- → ?
tracking-firefox60:
--- → ?
Comment 5•6 years ago
|
||
It is a bit late to fix this for 59 but we can still consider a patch for 60/61.
Updated•6 years ago
|
tracking-firefox60:
? → ---
Summary: when Title Bar is diabled, page elements and popups are drawn in the wrong location → when Title Bar is disabled, page elements and popups are drawn in the wrong location
Updated•6 years ago
|
status-firefox58:
--- → unaffected
status-firefox-esr52:
--- → unaffected
tracking-firefox60:
--- → ?
Comment 6•6 years ago
|
||
Is disabled title bar a common occurrence?
Reporter | ||
Comment 7•6 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #6) > Is disabled title bar a common occurrence? It's a recently added feature for Linux. The disabled titlebar isn't the problem, it's a setting. The problem occurs when the setting is activated. The issue (misaligned context menus and select dropdown menus) also seems to disappear if the window is maximized.
Comment 8•6 years ago
|
||
Non-default pref setting, doesn't sound worth tracking.
Reporter | ||
Comment 9•6 years ago
|
||
you're joking, right?
Updated•6 years ago
|
Blocks: gtktitlebar
Assignee | ||
Comment 10•6 years ago
|
||
Which WM/DE do you run? Can you please attach a screenshot of the issue?
Flags: needinfo?(commander.commando)
Reporter | ||
Comment 11•6 years ago
|
||
I use Deepin desktop and GNOME desktop, and the behavior appears on both. You can see the behavior in this screen capture: https://i.imgur.com/6qWBXY9.gifv
Flags: needinfo?(commander.commando)
Reporter | ||
Comment 12•6 years ago
|
||
This screen recording shows the behavior described in this bug. At the beginning, Firefox's titlebar is enabled, showing the correct context menu placement. Then the titlebar is disabled and the context menu is shown being drawn in the wrong location. The "drag space" setting is changed to show that has no effect on the behavior.
Assignee | ||
Comment 13•6 years ago
|
||
(In reply to commander.commando from comment #12) > Created attachment 8958523 [details] > Screen Capture displaying issue > > This screen recording shows the behavior described in this bug. At the > beginning, Firefox's titlebar is enabled, showing the correct context menu > placement. Then the titlebar is disabled and the context menu is shown being > drawn in the wrong location. The "drag space" setting is changed to show > that has no effect on the behavior. Great, Thanks. Which distro and gtk3 version do you run?
Flags: needinfo?(commander.commando)
Reporter | ||
Comment 14•6 years ago
|
||
(In reply to Martin Stránský [:stransky] from comment #13) > (In reply to commander.commando from comment #12) > > Created attachment 8958523 [details] > > Screen Capture displaying issue > > > > This screen recording shows the behavior described in this bug. At the > > beginning, Firefox's titlebar is enabled, showing the correct context menu > > placement. Then the titlebar is disabled and the context menu is shown being > > drawn in the wrong location. The "drag space" setting is changed to show > > that has no effect on the behavior. > > Great, Thanks. Which distro and gtk3 version do you run? My main distro is Arch (GTK 3.22.28, Intel/NVidia driver with Optimus, Firefox runs under the normal Intel driver), but I also see it on another machine running Debian (GTK 3.22.17, NVidia proprietary driver).
Flags: needinfo?(commander.commando)
Comment 15•6 years ago
|
||
(In reply to Alice0775 White from comment #2) > I can reproduce the issue context menu and select element on Linux Mint. Linux Mint 18.2 64bit MATE edition (running on VirtualBox5.2.8 Windows10 64bit) GTK 3.18.9-1ubuntu3.3
Updated•6 years ago
|
status-firefox61:
--- → affected
Assignee | ||
Comment 17•6 years ago
|
||
Yes, I can reproduce that on MATE and on pages which are run as remote (e10s).
Summary: when Title Bar is disabled, page elements and popups are drawn in the wrong location → [MATE][e10s] when Title Bar is disabled, page elements and popups are drawn in the wrong location
Assignee | ||
Updated•6 years ago
|
Assignee: nobody → stransky
Assignee | ||
Comment 18•6 years ago
|
||
It should be fixed by Bug 1424974 but this fix seems to be insufficient for some DE.
See Also: → 1424974
Assignee | ||
Comment 19•6 years ago
|
||
From some reason we don't get _NET_FRAME_EXTENTS message on MATE when titlebar if off so we don't set client offset here.
Assignee | ||
Comment 20•6 years ago
|
||
Seems to be a general problem with MOZ_GTK_TITLEBAR_DECORATION=client (CSD enabled). MOZ_GTK_TITLEBAR_DECORATION=client fails even on gnome-shell but MOZ_GTK_TITLEBAR_DECORATION=system works - _NET_FRAME_EXTENTS is sent to our toplevel window.
Assignee | ||
Comment 21•6 years ago
|
||
Another problem is that when CSD titlebar mode is used we need to re-create toplevel mGdkWindow as it's destroyed during reparenting mContainer. We need to update client offset, WM hints, WindowClass...
Reporter | ||
Comment 22•6 years ago
|
||
I can alleviate the issue on my machine by setting XDG_CURRENT_DESKTOP=GNOME, which resolves the problem even on non-GNOME desktops.
Assignee | ||
Updated•6 years ago
|
Summary: [MATE][e10s] when Title Bar is disabled, page elements and popups are drawn in the wrong location → [MATE] when Title Bar is disabled, page elements and popups are drawn in the wrong location
Comment hidden (mozreview-request) |
Comment 24•6 years ago
|
||
mozreview-review |
Comment on attachment 8970453 [details] Bug 1441665 - [Gtk] Update window offset explicitly when titlebar is disabled in CSD mode, https://reviewboard.mozilla.org/r/239228/#review244902 ::: widget/gtk/gtk3drawing.cpp:3038 (Diff revision 1) > +GetCSDDecorationSize(GtkBorder* aDecorationSize) > +{ > + GtkStyleContext* context = GetStyleContext(MOZ_GTK_WINDOW_DECORATION); > + > + /* Always sum border + padding */ > + GtkBorder p; name it padding instead of just p. ::: widget/gtk/nsWindow.cpp:6591 (Diff revision 1) > } > } > } > > +/* nsWindow::UpdateClientOffsetForCSDWindow() is designed to be called from > + * pain code to update mClientOffset any time. It also propagates pain/paint
Attachment #8970453 -
Flags: review?(jhorak) → review+
Comment hidden (mozreview-request) |
Comment 26•6 years ago
|
||
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/de3a44bd989c [Gtk] Update window offset explicitly when titlebar is disabled in CSD mode, r=jhorak
Comment 27•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/de3a44bd989c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
Comment 28•6 years ago
|
||
Should this be uplifted?
Assignee | ||
Comment 29•6 years ago
|
||
(In reply to QwertyChouskie from comment #28) > Should this be uplifted? Yes, definitely, it's very annoying bug.
Assignee | ||
Comment 30•6 years ago
|
||
Comment on attachment 8970453 [details] Bug 1441665 - [Gtk] Update window offset explicitly when titlebar is disabled in CSD mode, Approval Request Comment [Feature/Bug causing the regression]: none (it's missing functionality) [User impact if declined]: When titlebar is disabled on Linux, popup menus is displaced on some DE (Mate, KDE) [Is this code covered by automated tests?]: no [Has the fix been verified in Nightly?]: no (but it's checked in) [Needs manual test from QE? If yes, steps to reproduce]: Yes, disable titlebar at customize, click by right mouse button and check if the popup menu is at correct location. [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: low risk [Why is the change risky/not risky?]: Linux/Gtk+ only, used by feature which is off by default. It's isolated change when we create/configure out top level windows. [String changes made/needed]:
Attachment #8970453 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 31•6 years ago
|
||
Can someone confirm the fix at nightly as we request the uplift here? Thanks!
Flags: needinfo?(commander.commando)
Assignee | ||
Updated•6 years ago
|
Summary: [MATE] when Title Bar is disabled, page elements and popups are drawn in the wrong location → [CSD] when Title Bar is disabled, page elements and popups are drawn in the wrong location
Reporter | ||
Comment 32•6 years ago
|
||
I am unable to confirm the fix. Since my workaround is to set XDG_CURRENT_DESKTOP=GNOME to resolve the problem on non-GNOME desktops, and because Disable Titlebar has (again) been disabled entirely without that env var, I can't verify that elements are still drawn correctly without the title bar after removing the workaround. I don't have a GNOME desktop available to test on, but the problem hasn't presented under GNOME for some time anyway (due to XDG_CURRENT_DESKTOP being set to GNOME anyway, I would imagine).
Flags: needinfo?(commander.commando)
Assignee | ||
Comment 33•6 years ago
|
||
Hm, and which desktop do you run? AFAIK we support most of the available environmend...what's your original XDG_CURRENT_DESKTOP value? Also you don't need to set XDG_CURRENT_DESKTOP to select your decoration mode. You can set Mozilla specific value MOZ_GTK_TITLEBAR_DECORATION, by: MOZ_GTK_TITLEBAR_DECORATION=client - CSD decoration mode (for MATE, KDE,...) MOZ_GTK_TITLEBAR_DECORATION=system - window manager decoration mode (for Gnome-shell, Cinamon)
Flags: needinfo?(commander.commando)
Comment on attachment 8970453 [details] Bug 1441665 - [Gtk] Update window offset explicitly when titlebar is disabled in CSD mode, This does not sound like a must-fix for 60. I'd prefer to let this one ride the 61 train.
Attachment #8970453 -
Flags: approval-mozilla-beta? → approval-mozilla-beta-
Assignee | ||
Comment 35•6 years ago
|
||
(In reply to Ritu Kothari (:ritu) from comment #34) > Comment on attachment 8970453 [details] > Bug 1441665 - [Gtk] Update window offset explicitly when titlebar is > disabled in CSD mode, > > This does not sound like a must-fix for 60. I'd prefer to let this one ride > the 61 train. Okay, let's fine tune the KDE experience for 61.
Flags: needinfo?(commander.commando)
Assignee | ||
Comment 36•6 years ago
|
||
We need also implement this for maximized window - filed as Bug 1457309.
See Also: → 1457309
You need to log in
before you can comment on or make changes to this bug.
Description
•