[Webkit-unassigned] [Bug 229116] [GTK] WebkitWebView might loads twice if sharing same WebKitWebContext

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=229116

Michael Catanzaro <mcatanzaro at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at gnome.org

--- Comment #1 from Michael Catanzaro <mcatanzaro at gnome.org> ---
Unfortunately WebKit is invoking the WebKitURISchemeRequestCallback multiple times with the same WebKitURISchemeRequest object. Then WebKit gets very confused because the application called webkit_uri_scheme_request_finish() multiple times with the same object, but this is WebKit's fault for reusing the same WebKitURISchemeRequest in the first place. It actually trips an assert in WebKit::WebKitURISchemeHandler::platformStartTask, in WebKitWebContext.cpp:

ASSERT(addResult.isNewEntry);

but we compile out ASSERTs in release builds, and nobody tests debug builds because they ASSERT too much, because nobody tests debug builds. :)

The problem is that the UI process uses task IDs to distinguish between different WebURLSchemeTask objects, and reasonably expects the task IDs to be globally-unique. But the task IDs are actually generated in the web process in WebURLSchemeTaskProxy::startLoading using ResourceLoader::identifier, which uses ProgressTracker::createUniqueIdentifier, which just increments a counter variable, so they're only unique to a given web process, not unique in the web process. In your test program, all 10 tasks have the same ID: 1. Oops!

It's a cross-platform bug btw, nothing GTK-specific here. Probably not hard to fix, but I'm too tired to think it through tonight.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210908/fb3d8b9c/attachment.htm>