1958174 - [bspwm/dwm] Small gap between scrollbar and edge of the screen since Firefox 137

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P3)

Description

[Martin Tournoij]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

Since Firefox 137, there seems to be a small gap between the scrollbar and the edge of my screen.

This is not a visual issue: moving my mouse to the side of the screen to use the scrollbar no longer works, I need to move it to the edge of the scree and then a few pixels back. It's a pretty annoying.

I installed a new FreeBSD machine yesterday where I first observed this. Today I updated my main Linux machine from 136 to 137 and it has the same. The FreeBSD is a new profile, and I made sure to test with a brand new profile on Linux too.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Can you attach a screenshot of it? Can you use moregression to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks.

Comment 3

[jayisoverhere]

hope this isnt impeding, mozregression output:

4:33.57 INFO: Narrowed integration regression window from [8b410273, 9efb94e5] (4 builds) to [ff5432cc, 9efb94e5] (2 builds) (~1 steps left)
4:33.57 INFO: No more integration revisions, bisection finished.
4:33.57 INFO: Last good revision: ff5432cc7e7c0d223330a7c8f09a89d797793f83
4:33.57 INFO: First bad revision: 9efb94e533503b0cd1309c16d01d488a69941059
4:33.57 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ff5432cc7e7c0d223330a7c8f09a89d797793f83&tochange=9efb94e533503b0cd1309c16d01d488a69941059

i have a gap between the top and right side of the window, which creates a mouse click offset of that size as well (changing hardware accel settings in about:config seems to change, but not remove this behavior). seems to be the same issue as OP.

Comment 4

[jayisoverhere]

Attachment: 1958174-screenshot.png

Comment 5

[Martin Tournoij]

I had the same bisect as jayisoverhere in https://bugzilla.mozilla.org/show_bug.cgi?id=1958174#c3 when I ran it this morning. I didn't post it yet as I also discovered that it seems to depend on the window manager: if I start xfce it works in both 136 and 137, but in dwm it doesn't and I wanted to investigate a bit further when I have some time. Which WM are you using Jay?

Can you attach a screenshot of it?

Both versions are pixel-identical; there isn't really anything to see. It "overshoots" the scrollbar by one or two pixels and it behaves as if it loses focus.

Comment 6

[jayisoverhere]

Which WM are you using Jay?

bspwm- this is a xwindow border value related issue. if the xwindow is using a border size of 0 this doesnt happen- so reparenting WMs will probably not show this

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 581863, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Ok it took a bit to set up but I can reproduce that, even on Nightly. Will look. It seems we might be accounting for the border twice somehow, or something along those lines.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Well, turns out this is a (very long-standing) GTK bug. Fixes for GTK3 and GTK4 at:

• https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8423
• https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/8424

Respectively.

I'd be willing to add a workaround in Firefox, but it turns out to be not straight-forward, because we don't know if the width is correct or not unless we either re-implement gdk_window_get_frame_extents locally (let's not), or add some somewhat-slow server calls to check if the window has a border and then manually add it... Yuck.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 581863

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1958174 - Add a workaround for a GTK X11 bug in gtk_window_get_frame_extents. r=stransky

Kinda ugly, but this seems to be enough to fix the issue on bspwm...

Assuming it doesn't cause performance regressions it doesn't seem too
bad. GTK sometimes queries the X window tree, I hope we don't really
need to do that...

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Ok, prototyped something that works and isn't too bad...

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Tried dwm as well where by default the effect is very subtle. Workaround also seems to fix it.

Comment 14

[Martin Tournoij]

Thanks; can confirm the gtk3 patch fixes it for me.

Didn't try the workaround in Firefox patch, as building Firefox is generally a bit of a pain (or at least, was last time I tried).

Comment 15

[jayisoverhere]

will add for reference that the firefox patch also fixes the issue (username ortango on the bspwm issue report @ github).

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/766ad9442092
Add a workaround for a GTK X11 bug in gtk_window_get_frame_extents. r=stransky

Comment 17

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/766ad9442092

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox138 to wontfix.

For more information, please visit BugBot documentation.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

The GTK fix was merged, so we should add a version check before uplifting at least...

Comment 22

[Martin Tournoij]

It seems the workaround in Firefox 139 doesn't work, at least not for me in dwm?

I just decided to use a patched GTK until the fix is in a release, so it's okay – no action needed on my account. But just FYI.

Comment 23

[Martin Tournoij]

Actually looking at the patch, I think the version check might be wrong? Unless I'm misreading it, it checks for "!gtk_check_version(3, 24, 35)", but I'm on GTK 3.24.49 (which doesn't have this fix). Should probably be "!gtk_check_version(3, 24, 50)" (the next version which will include the fix)?

Comment 24

[Emilio Cobos Álvarez (:emilio)]

Hmm, isn't that what this is checking? https://searchfox.org/mozilla-central/rev/c66e658296cd024ee6ab8330350bfde7c1f05d38/widget/gtk/nsWindow.cpp#3257

Comment 25

[Martin Tournoij]

Right; I just looked at the hg link from earlier comment (https://bugzilla.mozilla.org/show_bug.cgi?id=1958174#c16) so guess that's incomplete 🙃