<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [SOUP] Network process crash in WebKit::CustomProtocolManagerImpl::didFailWithError"
href="https://bugs.webkit.org/show_bug.cgi?id=165082#c13">Comment # 13</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [SOUP] Network process crash in WebKit::CustomProtocolManagerImpl::didFailWithError"
href="https://bugs.webkit.org/show_bug.cgi?id=165082">bug 165082</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=165082#c12">comment #12</a>)
<span class="quote">> I just verified that the API test added in r149194 passes on Mac with
> CustomProtocolManager being a MessageReceiver instead of a
> WorkQueueMessageReceiver. I did this with and without NetworkSession, but
> with NetworkSession also requires changing globalCustomProtocolManager() to
> be a std::unique_ptr and setCustomProtocolManager to call the
> std::unique_ptr constructor explicitly.
> Let's give it a shot and see what Andy says. We don't have many clients
> using WebKit2's CustomProtocolManager because it's not public API, so it's
> possible we have a similar thread safety issue on Mac and just don't get a
> lot of stack traces.</span >
In mac the manager is thread safe, the registered schemes were protected in r149198, in r149520 methods were dispatched to the main thread and in r149121 mutex were added. I think we should revert all those things if we change to use message receiver again. There are a lot of changes in mac code that I can't test myself, but I can try.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>