gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2020-09-27T02:34:43Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/2710Differences between titlebar click behavior in CSD vs SSD (or weston terminal)2020-09-27T02:34:43ZAdam GoodeDifferences between titlebar click behavior in CSD vs SSD (or weston terminal)## Steps to reproduce
1. Build gtk 3.24.
2. (optionally) Disable raise-on-click.
3. Run examples/application1 and drag the window around.
4. Run examples/application10 and drag the window around.
## Current behavior
### gtk 3.24
...## Steps to reproduce
1. Build gtk 3.24.
2. (optionally) Disable raise-on-click.
3. Run examples/application1 and drag the window around.
4. Run examples/application10 and drag the window around.
## Current behavior
### gtk 3.24
On X11 (Gnome Shell), with raise-on-click disabled, application1 is drawn with server-side decorations. When I mouse-down on the titlebar, the cursor immediately changes to the window-moving icon and I immediately start to drag the window. The window does not raise on mouse-down. If I move the window by only a small amount (or zero), the window raises on mouse-up.
application10 is drawn with client-side decorations. On mouse-down in the titlebar, the window raises immediately. When I drag the window, the cursor stays the same and it does not move at all until I've moved by a certain amount. At that point, the window manager takes over the move and the behavior is the same as application1.
As a comparison, the weston terminal has similar behavior to application1, even though it is using client-side decorations (and raise-on-click cannot be disabled, so raising is immediate).
### git head
application1 behaves as in gtk 3.24. application10 cannot be raised by a click on the titlebar. Otherwise, the behavior is the same.
## Expected outcome
I am neutral on the delay in calling gdk_window_begin_move_drag_for_device() on client-side decorations. I am more concerned about the raise behavior. The current gtk-3 behavior was added in response to https://bugzilla.redhat.com/show_bug.cgi?id=1158472 which I filed 5 years ago, which fixed the problem of CSD windows not raising at all when clicked on. That was a simple solution to my bug, but in retrospect, it is probably not correct to call gdk_window_raise() directly here.
It looks like gnome-shell at least has the correct logic for raising windows provided that gdk_window_begin_move_drag_for_device() is called immediately on mouse down in the titlebar. By passing control early to the window manager, it can consistently apply its own move and raise behavior across all windows in the system.
I would suggest that the gtkwindow code be reworked to call gdk_window_begin_move_drag_for_device() immediately on mouse-down in the titlebar. This may also be a good way to fix this problem again in gtk 4.
Wayland still does not properly support raise-on-click disabled, but I would still like to find a way to make that work. I'm hoping that any simplification in the gtk window handling code could help make that easier.
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
Built 3.24 and head from git with no options.
Fedora 32. X11, with raise-on-click disabled.
## Additional information
<!--
- Screenshots or screen recordings are useful for visual errors
- Please report any warning or message printed on the terminal
-->https://gitlab.gnome.org/GNOME/gtk/-/issues/2087GtkHeaderBar rightclick on element in headerbar focuses the item, causing lef...2020-10-03T03:35:28ZOndřej KolínGtkHeaderBar rightclick on element in headerbar focuses the item, causing left somewhere else activate that item## Steps to reproduce
1. Open Nautilus, Gnome-settings, etc. (hope this is really gtk related)
2. Rightclick an item in the Header bar (for example the menu), this brings up the generic menu in Gnome Shell/Mutter
3. Left click somewh...## Steps to reproduce
1. Open Nautilus, Gnome-settings, etc. (hope this is really gtk related)
2. Rightclick an item in the Header bar (for example the menu), this brings up the generic menu in Gnome Shell/Mutter
3. Left click somewhere else in header bar to cancel it
4. Repeat the left click and the widget we previously rightclicked on will be activated
Tested in GTK Demo as well
## Current behavior
The item gets activated
## Expected outcome
The item should not be activated
## Version information
Fedora 30
Gnome Shell 3.32.2
gtk3.x86_64 3.24.10-1.fc30 @updates
## Additional information
![video](/uploads/7aa0f145795e7d4a14a73f0f2744ad39/video.webm)https://gitlab.gnome.org/GNOME/gtk/-/issues/1689[Firefox] When GtkHeaderBar is removed from toplevel window some parts of the...2019-02-25T19:37:45ZMartin Stransky[Firefox] When GtkHeaderBar is removed from toplevel window some parts of the window do not get mouse eventsThis is mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1527315
When titlebar rendering is turned off (for instance print preview is activated) some parts of Firefox window are not clickable (buttons, scrollbars). Happens only ...This is mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=1527315
When titlebar rendering is turned off (for instance print preview is activated) some parts of Firefox window are not clickable (buttons, scrollbars). Happens only in CSD mode. There's a simple testcase attached:
[gtk-empty-titlebar.cpp](/uploads/b6841f9d8fa3b63943496d6c320bb352/gtk-empty-titlebar.cpp)
0) build it
1) run gtk-empty-titlebar, you'll get empty window without the titlebar (that's intentional as Firefox draws it's own titlebar)
2) click anywhere at the window. CSD mode will be disabled and window manager decorations will be enabled
3) enlarge the window or make it fullscreen
4) click at the new window area which was added in step 3)
5) the new area is not clickable. Only the old window parts which was there before step 3 are clickable.https://gitlab.gnome.org/GNOME/gtk/-/issues/583GtkHeaderBar: Close button's mouse-over area doesn't extend to top-right pixe...2023-09-26T12:51:48ZBugzillaGtkHeaderBar: Close button's mouse-over area doesn't extend to top-right pixel when maximized (fitts' law)## Submitted by Jan Niklas Hasse `@jhasse`
**[Link to original bug (#758244)](https://bugzilla.gnome.org/show_bug.cgi?id=758244)**
## Description
Created attachment 315791
Left: working, Right: not working
Running GNOME Shell with ...## Submitted by Jan Niklas Hasse `@jhasse`
**[Link to original bug (#758244)](https://bugzilla.gnome.org/show_bug.cgi?id=758244)**
## Description
Created attachment 315791
Left: working, Right: not working
Running GNOME Shell with a bottom panel it's not possible to close a maximized window of an application that is using GtkHeaderBar by clicking the most top-right pixel.
My screen-shot shot shows what I mean: On the left there's a traditional application not using GtkHeaderBar. The red pixel is my mouse position. As you can see this triggers the mouse over of the close button, but not with a GtkHeaderBar as you can see on the right side.
**Attachment 315791**, "Left: working, Right: not working":
![example](/uploads/a65ccbd82bce49a2d7cd90d212c54d46/example.png)
Version: 3.14.x
### See also
* [Bug 112007](https://bugzilla.gnome.org/show_bug.cgi?id=112007)https://gitlab.gnome.org/GNOME/gtk/-/issues/489Decoration buttons do not follow custom specified layout in desktop environment2020-10-01T21:28:45ZBugzillaDecoration buttons do not follow custom specified layout in desktop environment## Submitted by Martin Gräßlin
**[Link to original bug (#729784)](https://bugzilla.gnome.org/show_bug.cgi?id=729784)**
## Description
Created attachment 276131
Wrong close button position
Some desktop environments (like Plasma) all...## Submitted by Martin Gräßlin
**[Link to original bug (#729784)](https://bugzilla.gnome.org/show_bug.cgi?id=729784)**
## Description
Created attachment 276131
Wrong close button position
Some desktop environments (like Plasma) allow to specify the layout of window decoration buttons. GTK+ applications do not honor these settings, making them being the odd spot when the general close button is on the left.
Steps to reproduce:
1. Run Plasma session
2. Configure window decoration to have close button on the left
3. Start gtk3-demo
Actual Result:
close button is on the right
Expected Result:
close button is on the left
See the attached screenshot highlighting the issue using the double decorated on non-compositing bug (see [bug 729769](https://bugzilla.gnome.org/show_bug.cgi?id=729769)).
**Attachment 276131**, "Wrong close button position":
![wrong-close-button-position](/uploads/0ede65da4cf2404c57c6975d410718db/wrong-close-button-position.png)
Version: 3.12.x
### Blocking
* [Bug 729721](https://bugzilla.gnome.org/show_bug.cgi?id=729721)