Bug 111052

Summary: [Mac] [WK1] http/tests/xmlhttprequest/navigation-should-abort.html fails
Product: WebKit Reporter: Ryosuke Niwa <rniwa>
Component: Page LoadingAssignee: Mike West <mkwst>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, beidson, mkwst, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch for landing none

Description Ryosuke Niwa 2013-02-28 01:29:54 PST
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&showExpectations=true&tests=http%2Ftests%2Fxmlhttprequest%2Fnavigation-should-abort.html

e.g.
http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK1%20(Tests)/r144222%20(7353)/results.html

--- /Volumes/Data/slave/mountainlion-release-tests-wk1/build/layout-test-results/http/tests/xmlhttprequest/navigation-should-abort-expected.txt
+++ /Volumes/Data/slave/mountainlion-release-tests-wk1/build/layout-test-results/http/tests/xmlhttprequest/navigation-should-abort-actual.txt
@@ -1,2 +1,2 @@
 CONSOLE MESSAGE: line 14: PASS: Expected 'abort', got 'abort'.
-This page should load, and the XMLHttpRequest from the previous page should have aborted and fired a 'PASS' message to the console.
+
Comment 1 Mike West 2013-02-28 01:37:02 PST
Thanks for the heads-up, rniwa.

That's a very strange failure: the text that's missing is the text that should be rendered on the page to which the test navigates. Happily, the thing we're actually testing (abort) seems to work correctly. :)
Comment 2 Ryosuke Niwa 2013-02-28 01:42:00 PST
Added test expectations in http://trac.webkit.org/changeset/144277.
Comment 3 Mike West 2013-02-28 02:57:03 PST
Hrm. This doesn't fail locally, but fails every time on the bots. I'll keep poking at it.
Comment 4 Ryosuke Niwa 2013-02-28 03:07:47 PST
(In reply to comment #3)
> Hrm. This doesn't fail locally, but fails every time on the bots. I'll keep poking at it.

Look at what tests are ran before running this one? Maybe tests are interfering with each other.
Comment 5 Mike West 2013-02-28 03:38:28 PST
(In reply to comment #4)
> (In reply to comment #3)
> > Hrm. This doesn't fail locally, but fails every time on the bots. I'll keep poking at it.
> 
> Look at what tests are ran before running this one? Maybe tests are interfering with each other.

Ah, I'm an idiot. I rolled past r144277 before building. Unskipping the test shows the failure. :)
Comment 6 Mike West 2013-02-28 03:56:16 PST
Created attachment 190696 [details]
Patch
Comment 7 Alexey Proskuryakov 2013-02-28 09:13:42 PST
Comment on attachment 190696 [details]
Patch

Hmm. But why is data: different? It loads just like any other resource, maybe just a little faster.
Comment 8 Mike West 2013-02-28 10:00:03 PST
(In reply to comment #7)
> (From update of attachment 190696 [details])
> Hmm. But why is data: different? It loads just like any other resource, maybe just a little faster.

I don't know. It's obviously performing the navigation, as the XMLHttpRequest is aborted correctly. I don't understand why it wouldn't render the 'data:' after navigation; the normal page works just fine.

It's limited to Mac WK1 as well, which is also odd. I would expect either the other mac ports to have the same issue, or the other WK1 ports.
Comment 9 Alexey Proskuryakov 2013-02-28 10:03:55 PST
Comment on attachment 190696 [details]
Patch

I guess this patch is OK to land, although it's only papering over whatever problem causes the issue.
Comment 10 Alexey Proskuryakov 2013-02-28 10:04:19 PST
I'd make it clearer in ChangeLog that we don't think that we got to the bottom of this.
Comment 11 Ryosuke Niwa 2013-02-28 21:30:51 PST
Comment on attachment 190696 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=190696&action=review

> LayoutTests/ChangeLog:11
> +        Currently, this test is failing to output the textual content of the
> +        'data:' URL to which the test navigates. Replacing this 'data:' URL
> +        with a "real" HTML file ensures that Mac WK1 behaves the same way as
> +        the other ports for this test.

Isn't this a bug in Mac WK1?
Comment 12 Mike West 2013-03-01 00:41:40 PST
Created attachment 190902 [details]
Patch for landing
Comment 13 Mike West 2013-03-01 00:42:05 PST
(In reply to comment #10)
> I'd make it clearer in ChangeLog that we don't think that we got to the bottom of this.

Throwing this into the CQ: I filed https://bugs.webkit.org/show_bug.cgi?id=111152 and adjusted the ChangeLog accordingly.

Thanks!
Comment 14 WebKit Review Bot 2013-03-01 01:47:45 PST
Comment on attachment 190902 [details]
Patch for landing

Clearing flags on attachment: 190902

Committed r144430: <http://trac.webkit.org/changeset/144430>
Comment 15 WebKit Review Bot 2013-03-01 01:47:49 PST
All reviewed patches have been landed.  Closing bug.