Bug 299984

Created attachment 476937 [details] webkit://gpu OS and hardware info: - Fedora Linux 42 (Workstation Edition) - GNOME 48 (Wayland) - Linux 6.16.8 - GStreamer 1.26.6 - GTK 4.18.6 - Intel Core i5-1155G7 - Intel Iris Xe Some examples: - bugs.webkit.org (DOESN'T trigger) - github.com (DOESN'T trigger) - gitlab.com (DOESN'T trigger) - webkitgtk.org (DOESN'T trigger) - apple.com (DOESN'T trigger) - discussion.fedoraproject.org (DOESN'T trigger) - mailchimp.com (TRIGGER)

Other examples: - bagisto.com (DOESN'T trigger) - sylius.com (DOESN'T trigger) - udemy.com (DOESN'T trigger) - dyson.com (DOESN'T trigger) - rowenta.com (DOESN'T trigger) - koji.fedoraproject.com (DOESN'T trigger) - duolingo.com (DOESN'T trigger) - sony.com (DOESN'T trigger) - europarl.europa.eu (TRIGGER) I want to specify that once triggered, it's not sufficient to close the tab, but you need to completely close the browser to restore normal behavior.

I should clarify that I can't reproduce the issue consistently on the same site. Perhaps it also depends on the number of open tabs. I couldn't say for sure. It's very strange behavior.

Created attachment 477000 [details] screenshot of the issue 1

Created attachment 477001 [details] screenshot of the issue 2

I keep having the same problem even on 2.50.4

I'm able to reproduce it reliably in GNOME Web. Just have three tabs open to any random web page and then open https://mailchimp.com/ in the 4th tab, that tab with the WebKitWebProcess will pin a single core to 100% until the tab is closed. WebKitGTK 2.52.3 GStreamer 1.26.11 GTK 4.20.4 Libadwaita 1.8.5 Distributor: 'Gentoo'

It still persists on 2.52.4

I found a fairly reliable way to reproduce the issue: go to europass.europa.eu and click on 'Login to Europass'. In this case two problems occur: the login page does not open (but it works on Safari); the CPU is triggered and goes to maximum in single core. Sometimes (very few) it happens that everything works perfectly without problems: if this happens, close the browser and try again. BTW: despite asking for clarification on how to use gdb in this case, I was unable to get a backtrace consistent with the problem; so if anyone else wants to try it is welcome, otherwise I await clearer instructions (step-by-step please).

Same issue when Alpaca (https://jeffser.com/alpaca/) uses web search tool.

Created attachment 481112 [details] Sysprof capture - loading and idling on europass.europa.eu's English home page This is the result of telling Sysprof to launch: epiphany -i https://europass.europa.eu/en/home Using the "Marks" view, you can see where the loading stops (due to lack of compositor activity etc.) and when it starts idling, and filter the two parts of the timeline to see the difference in the Flamegraph view. On my laptop, that website's home page constantly uses about ~25% "undivided" CPU while idle / loaded.

Created attachment 481113 [details] Sysprof capture - loading and idling on europass.europa.eu login page This is the result of telling Sysprof to run the login page directly: epiphany -i https://europa.eu/europass/eportfolio/api/europass-auth/authenticate?redirect_uri=https://europa.eu/europass/eportfolio/screen/mfa?lang=en This one shows very different flamegraphs because it takes a lot longer to load, with lots of fonts-related things in the flamegraph's first part (until 23.25 seconds), which makes the loading slowness part look like bug #315135. After loading, the login page doesn't seem to consume significant amounts of CPU on my laptop, unlike the decorative home page mentioned in my previous comment above with the other sysprof capture.

Created attachment 481115 [details] Sysprof capture - loading and idling on Mailchimp front page This is the result of telling Sysprof to launch: epiphany -i https://mailchimp.com/en/ This one also eats similar amounts of CPU while idle. The "Marks" view tells me that the page loading completes after around 17 seconds (no more compositor activity), so you probably want to filter the timeline to 17 seconds onwards to see what it's doing while idling.