Bug 192004 – [GTK] WebKitWebView fails to close when the network process is hung

• Status: RESOLVED
• Resolution: MOVED
• Component: WebKitGTK

[Andres Gomez Garcia]

I'm using epiphany 3.31.2-11-g474e55d7 with WebKitGtk+ 2.22.3 from gnome-nightly's flatpak, although it has been happening already for some previous versions.

When accessing some specific URLs, ephy freezes. I cannot close tabs, close the whole session or continue browsing. This is not the actual problem reported here. It is being tracked at:
https://gitlab.gnome.org/GNOME/glib-networking/issues/46

The problem is that, using Ctrl+Q doesn't work. It half closes the session, though, leaving only opened the first window opened and the window in which the frozen tab has happened.

This shouldn't happen since webkit_web_view_close() ought to work even when network process is hung.

This URL might show this behavior: https://incomplete-chain.badssl.com/

[Michael Catanzaro]

(In reply to Andres Gomez Garcia from comment #0)
> This shouldn't happen since webkit_web_view_close() ought to work even when
> network process is hung.

Eh, turns out I made up that function, it doesn't exist. It's hanging in dispose.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #1)
> Eh, turns out I made up that function, it doesn't exist. It's hanging in
> dispose.

Nope, made that up too. Where is it hanging... seems this only happens if there are multiple tabs open....

[Michael Catanzaro]

OK, turns out that it's no problem to close the tab that triggers this deadlock, or any tab created before the deadlock is trigger. It's only tabs created afterwards that are not closeable. That's because Epiphany tries to run code in the web process during the tab close (Ephy.hasModifiedForms). That's probably the best we can do in the event of deadlock, so let's move this back to Epiphany to find a workaround there.

[Michael Catanzaro]

For the record: https://gitlab.gnome.org/GNOME/epiphany/issues/587