Summary: | [WebKit2] Loading a resource from a custom protocol in a synchronous XHR times out | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Andy Estes <aestes> | ||||
Component: | WebKit2 | Assignee: | Andy Estes <aestes> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | andersca, ap, beidson, darin, sam, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Mac | ||||||
OS: | All | ||||||
Attachments: |
|
Description
Andy Estes
2013-04-25 22:32:11 PDT
Created attachment 199785 [details]
Patch
Committed r149194: <http://trac.webkit.org/changeset/149194> This change means that messages are now handled on a secondary thread. What is the design for CustomProtocolManager thread safety? (In reply to comment #4) > This change means that messages are now handled on a secondary thread. What is the design for CustomProtocolManager thread safety? The messages that are handled on this thread do two things: 1) Look up a WKCustomProtocol by ID. This was made thread-safe in <http://trac.webkit.org/changeset/149121>. 2) Call a method on NSURLProtocolClient. I believe this is thread-safe by code inspection. (In reply to comment #4) > This change means that messages are now handled on a secondary thread. What is the design for CustomProtocolManager thread safety? Oh, we do need to protect m_registeredSchemes. We add/remove schemes to that set from the work queue but look them up from some thread managed by NSURLConnection. I'll fix that in a follow-up. Thanks for making me double-check! (In reply to comment #6) > I'll fix that in a follow-up. Filed <https://bugs.webkit.org/show_bug.cgi?id=115267>. |