Bug 164985
| Summary: | [GTK] Multiple WebkitGTK+ windows of the same application slow down | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Berend De Schouwer <berend.de.schouwer> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | bugs-noreply, carlosg, mcatanzaro |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=1396009 https://bugs.webkit.org/show_bug.cgi?id=164983 https://bugs.webkit.org/show_bug.cgi?id=164984 https://bugzilla.gnome.org/show_bug.cgi?id=769835 |
||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.