WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
110401
[chromium] http/tests/security/feed-urls-from-remote.html times out after
bug 109995
https://bugs.webkit.org/show_bug.cgi?id=110401
Summary
[chromium] http/tests/security/feed-urls-from-remote.html times out after bug...
Eric Seidel (no email)
Reported
2013-02-20 16:09:28 PST
DocumentLoader should think it's loading while the parser is still active
Attachments
Mostly for the EWSes to munch on.
(3.75 KB, patch)
2013-02-20 16:36 PST
,
Eric Seidel (no email)
webkit.review.bot
: commit-queue-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2013-02-20 16:36:45 PST
Created
attachment 189410
[details]
Mostly for the EWSes to munch on.
WebKit Review Bot
Comment 2
2013-02-20 18:18:24 PST
Comment on
attachment 189410
[details]
Mostly for the EWSes to munch on.
Attachment 189410
[details]
did not pass chromium-ews (chromium-xvfb): Output:
http://queues.webkit.org/results/16646691
New failing tests: http/tests/security/feed-urls-from-remote.html
Eric Seidel (no email)
Comment 3
2013-02-21 09:00:45 PST
Looking at the failure now.
Eric Seidel (no email)
Comment 4
2013-02-21 12:39:07 PST
Reduction of the hang: reduction.html: <script> testRunner.dumpAsText(); testRunner.waitUntilDone(); </script> <iframe src="feed.html" onLoad="testRunner.notifyDone()"></iframe> feed.html: <a id="myFeed">The feed:// URL</a> <script> var myFeed = document.getElementById("myFeed"); myFeed.href = "feed://127.0.0.1:" + document.location.port + "/security/resources/feed.xml"; var evt = document.createEvent("MouseEvents"); evt.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0, false, false, false, false, 0, null); myFeed.dispatchEvent(evt); </script> feed.xml: <empty> (can be anything)
Eric Seidel (no email)
Comment 5
2013-02-21 12:39:45 PST
I'm not sure if the feed: part is important. But a data url seemed to not cause the hang, and invalid urls also failed to hang.
Eric Seidel (no email)
Comment 6
2013-02-21 13:10:56 PST
Actually, that reduction times out even w/o my change. However, adding back the setCustomPolicyDelegate calls, makes it complete again!
Eric Seidel (no email)
Comment 7
2013-02-21 13:52:34 PST
So at first glance, this change seems to change behavior of the policyDelegate codepath in the loader, causing this one test which depended on this to fail. :) It's not clear yet if this is just a bug in Chromium's DRT, relating to this quirk in the policyDelgate codepath, or if this could be a real bug for the policyDelegate codepath (which would only affect Mac). Building Mac now.
Eric Seidel (no email)
Comment 8
2013-02-21 15:20:25 PST
More context: main.html: <script> testRunner.dumpAsText(); testRunner.waitUntilDone(); </script> <iframe src="resource.html" onLoad="testRunner.notifyDone()"></iframe> resource.html: <script> location.href = "feed://127.0.0.1:" + document.location.port + "/security/resources/feed.xml"; </script> Hangs Chromium DRT, but does not hang Mac (w/o the patch). Changing feed: to http: does not hang Chromium DRT (with or w/o the patch!)
Eric Seidel (no email)
Comment 9
2013-02-21 15:54:14 PST
Comment on
attachment 189410
[details]
Mostly for the EWSes to munch on. I'm going to complete this in
bug 109995
and leave this for solving the chromium DRT oddity (if we ever chose to). Most of the other tests in this directory are already marked Wontfix it seems.
Eric Seidel (no email)
Comment 10
2013-02-21 22:55:46 PST
bug 109995
also broke Mac WK1, seen in
bug 110554
.
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