On Apr 22, 2013, at 8:37 AM, Joe Mason <[email protected]> wrote:
> I'm trying to debug a deadlock on exit in a BlackBerry app that uses webkit > (which is pretty hard to reproduce, so I don't have a cut-down test case > yet). Right now my suspicions are on this behaviour: > > a synchronous XMLHttpRequest starts loading (from a script running in the > main frame) > ResourceHandle::platformLoadResourceSynchronously gets called > On BlackBerry, this is implemented by creating a nested EventLoop and calling > loop.cycle() > While in the nested event loop, BlackBerry::WebPage::stopLoading is called There's your problem - loadResourceSynchronously is supposed to guarantee that - from WebCore's perspective - the main web thread is waiting on the resource load. The nested event loop needs to be configured to *not* call back in to WebCore and *only* to service the load. Note that this expectation re: sync XHR is why single-process, Web-thread-is-UI-thread browsers are expected to become completely non responsive during the sync XHR. The proper way to allowing such an app to exit while a sync XHR is outstanding would be to cause the sync XHR load to fail at the networking layer *then* exit. ~Brady > This is implemented by calling m_mainFrame->loader()->stopAllLoaders() > > As far as I can see, FrameLoader::stopAllLoaders does NOT stop any > XMLHttpRequest started from this frame - it just stops the > provisionalDocumentLoader and documentLoader for the frame itself, and > recursively does the same for all subframes. Is that correct? > > Is there a way to find and stop all synchronous requests associated with a > frame? (There should be only one...) > > Thanks, > Joe > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
