Bug 52553 - [GTK] Many DOM XHTML tests time out
Summary: [GTK] Many DOM XHTML tests time out
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P3 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks:
 
Reported: 2011-01-16 23:08 PST by Martin Robinson
Modified: 2011-01-24 17:30 PST (History)
5 users (show)

See Also:


Attachments
Patch (3.86 KB, patch)
2011-01-16 23:17 PST, Martin Robinson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Robinson 2011-01-16 23:08:04 PST
Many tests in the dom/xhtml/level3/core/ directory seem to time out. From initial examination, the issue seems to be that the soup backend does not handle the failure of a synchronous load before the inner event loop has started.
Comment 1 Martin Robinson 2011-01-16 23:17:06 PST
Created attachment 79129 [details]
Patch
Comment 2 Eric Seidel (no email) 2011-01-24 15:44:39 PST
Comment on attachment 79129 [details]
Patch

Can't we run the loop with a timeout?  Or schedule a timeout event on the loop before we run it?  That seems like a more general fix for this problem than this specific exclusion.
Comment 3 Martin Robinson 2011-01-24 16:01:31 PST
(In reply to comment #2)
> (From update of attachment 79129 [details])
> Can't we run the loop with a timeout?  Or schedule a timeout event on the loop before we run it?  That seems like a more general fix for this problem than this specific exclusion.

I had considered a solution like this, but the details of the operation of the WebCoreSynchronousLoader are hidden from ResourceHandle::loadResourceSynchronously. Meanwhile, the handle itself "owns" the WebCoreSynchronousLoader (it's the client), so it didn't seem clean to add another relationship. I finally chose this approach because it matches the CF network code.
Comment 4 Martin Robinson 2011-01-24 16:02:18 PST
(In reply to comment #3)
> (In reply to comment #2)
> > (From update of attachment 79129 [details] [details])
> > Can't we run the loop with a timeout?  Or schedule a timeout event on the loop before we run it?  That seems like a more general fix for this problem than this specific exclusion.
> 
> I had considered a solution like this, but the details of the operation of the WebCoreSynchronousLoader are hidden from ResourceHandle::loadResourceSynchronously. Meanwhile, the handle itself "owns" the WebCoreSynchronousLoader (it's the client), so it didn't seem clean to add another relationship. I finally chose this approach because it matches the CF network code.

By the way, thanks for the review!
Comment 5 Martin Robinson 2011-01-24 16:47:24 PST
Comment on attachment 79129 [details]
Patch

Clearing flags on attachment: 79129

Committed r76555: <http://trac.webkit.org/changeset/76555>
Comment 6 Martin Robinson 2011-01-24 16:47:29 PST
All reviewed patches have been landed.  Closing bug.
Comment 7 WebKit Review Bot 2011-01-24 17:30:51 PST
http://trac.webkit.org/changeset/76555 might have broken GTK Linux 32-bit Release
The following tests are not passing:
http/tests/xmlhttprequest/simple-cross-origin-denied-events-post.html
http/tests/xmlhttprequest/simple-cross-origin-denied-events-sync.html
media/unsupported-rtsp.html