Bug 305290 – [GTK] Dragging the scrollbars becomes extremely slow after resizing the browser window (or webview) on some websites

• Component: WebKitGTK
• Status: NEW

[Jeff Fortin]

Created attachment 477966 [details]
Demonstration video

To reproduce:

1. /usr/libexec/webkitgtk-6.0/MiniBrowser --private https://thewalrus.ca/return-to-office-mandates/
…or use epiphany -i https://thewalrus.ca/return-to-office-mandates/

2. Wait for the page to load (or stop it mid-way using "Esc"), dismiss the subscription popovers if any

3. Move the mouse to hover the WebKitGTK webview's overlay scrollbar on the right

4. Drag the mouse up and down rapidly, notice it is smooth

5. Open a new tab and close it, or better: resize the browser's window a little bit (as shown in the video)

6. Drag the mouse up and down rapidly, notice it is now extremely slow (i.e. you get 2-3 fps on the view instead of 60), and that the scrollbar's position indicator is unable to keep up with the mouse.

Demonstration video, full Sysprof 49 captures, and screenshots attached.

Scrolling with the mouse wheel or touchpad does not exhibit the lagging view symptoms as strongly, however you can still see the scrollbar's position indicator lagging while you are scrolling with the touchpad.


# Hardware & OS info

This problem is reproducible with the latest versions of MiniBrowser and Epiphany (49 RPM and TP flatpak), on Fedora 42 and 43, on different computers. This was observed on:

* A ThinkPad T480 laptop with 8th gen Intel Kabylake chipset, at low-DPI on an external display, running GNOME Shell 48.7's Wayland session from Fedora 42. Over there, I tested WebKitGTK 2.50.4 with Epiphany 48.5 (from Fedora's repositories) and MiniBrowser, as well as Epiphany TP (nightly flatpak). This is the machine where I recorded the video.

* A HiDPI laptop with 8th gen Intel Kabylake chipset, with the built-in 4K display, running GNOME Shell 49.2's Wayland session from Fedora 43. Over there, I tested WebKitGTK 2.50.4 with Epiphany 49.2 from Fedora's repositories. This is the machine where I recorded the Sysprof captures.

[Jeff Fortin]

Created attachment 477967 [details]
Sysprof capture - before resizing the window

[Jeff Fortin]

Created attachment 477968 [details]
Sysprof capture - after resizing the window (manifest slow performance)

[Jeff Fortin]

Created attachment 477969 [details]
Screenshot of Sysprof flamegraph before resizing the window

[Jeff Fortin]

Created attachment 477970 [details]
Screenshot of Sysprof flamegraph after resizing the window

[Jeff Fortin]

Created attachment 477971 [details]
Screenshot of Sysprof marks before resizing the window

[Jeff Fortin]

Created attachment 477972 [details]
Screenshot of Sysprof marks after resizing the window

[Jeff Fortin]

The fact that this also happens when creating a new tab from a single private browsing window is probably because the newly shown tab bar causes the webview to resize vertically, so I would suspect this to be related to the webview being resized just like when you resize the window (which is the most straightforward way for me to test the issue).

On this computer, I currently have the "Always Show Scrollbars" accessibility setting turned off.

Interestingly enough, if I turn on the "Always Show Scrollbars" accessibility setting, Epiphany's webview will show the permanent scrollbar as "not an overlay" (i.e. no semi-transparency, no apparent compositing) yet the lag will still be the same, the bug will still occur.

[Carlos Garcia Campos]

At a first glance it looks like for some reason layout is slow (or called too many times) after resizing the window.