Bug 164985 – [GTK] Multiple WebkitGTK+ windows of the same application slow down

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Berend De Schouwer]

Running multiple Epiphany windows on different workspaces causes severe slowdown of all Epiphany windows.

Environment: Gnome-Shell on Wayland

Running multiple windows, where the windows are on a different workspace, cause the windows to appear frozen.  To unfreeze them it's necessary to provide each window time to update it's contents.  In other words: it's necessary to switch to each workspace that has a Epiphany window before the window is updated.

1. Start Epiphany on workspace 1
2. Start a new window, or detach a tab
3. Move that window to workspace 2
4. Load a page (bugs.webkit.org) on workspace 1
5. Go to workspace 2
6. Attempt to update the URL bar
   ... no/slow update
7. Go to workspace 1
8. Go to workspace 2
   ... updated

I haven't been able to confirm that this happens with an application other than Epiphany.

This is likely related to # 164983 since it's similarly required to focus the other workspaces to receive an update.

[Berend De Schouwer]

It's also necessary to cycle through the workspaces when *closing* epiphany windows.  Until the other workspace(s) have received focus, the windows aren't closed.

[Michael Catanzaro]

Turns out this needs to be fixed at GTK+ or maybe mesa level:

garnacho__:  mcatanzaro, KaL: turns out there was https://bugzilla.gnome.org/show_bug.cgi?id=769835
mcatanzaro:  garnacho__: Great find. I'll close the WebKit bug then?
garnacho__:  mcatanzaro: yeah I guess, there doesn't seem to be anything to fix here
mcatanzaro:  garnacho_: Does that also explain https://bugs.webkit.org/show_bug.cgi?id=164985?
garnacho__:  mcatanzaro: yeah, I think so, with the difference that the blocked state of the unmapped surface can be seen on a window in the current workspace

Ping-ponging this to GNOME Bugzilla for now.