WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
52553
[GTK] Many DOM XHTML tests time out
https://bugs.webkit.org/show_bug.cgi?id=52553
Summary
[GTK] Many DOM XHTML tests time out
Martin Robinson
Reported
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.
Attachments
Patch
(3.86 KB, patch)
2011-01-16 23:17 PST
,
Martin Robinson
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Martin Robinson
Comment 1
2011-01-16 23:17:06 PST
Created
attachment 79129
[details]
Patch
Eric Seidel (no email)
Comment 2
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.
Martin Robinson
Comment 3
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.
Martin Robinson
Comment 4
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!
Martin Robinson
Comment 5
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
>
Martin Robinson
Comment 6
2011-01-24 16:47:29 PST
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 7
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
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug