Bug 56537
Summary: | REGRESSION (r80050-r80060): http/tests/appcache/online-fallback-layering.html failing on SnowLeopard Intel Release (WebKit2 Tests) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Adam Roben (:aroben) <aroben> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW | ||
Severity: | Normal | CC: | ap, michaeln |
Priority: | P2 | Keywords: | InRadar, LayoutTestFailure, PlatformOnly, Regression |
Version: | 528+ (Nightly build) | ||
Hardware: | Mac | ||
OS: | OS X 10.6 | ||
URL: | http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r81319%20(9764)/http/tests/appcache/online-fallback-layering-pretty-diff.html |
Adam Roben (:aroben)
http/tests/appcache/online-fallback-layering.html is failing on SnowLeopard Intel Release (WebKit2 Tests). See the URL for the diff.
webkit-patch failure-reason says the regression happened in r80050-r80060.
Did not fail:
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/9154
Did fail:
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/9155
This is only failing on SnowLeopard, not on Windows.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Adam Roben (:aroben)
Checked in expected failure results in r81329.
Sam Weinig
<rdar://problem/9147574>
Michael Nordman
Here's the output of the test:
Test that a network namespace trumps a fallback namespace where they overlap.
Sanity check the presence of the fallback namespace, should get the fallback resource.
unexpected status code
FAIL - did not get the fallback resource
The unexpected status code is telling... this is possibly a result of...
https://bugs.webkit.org/show_bug.cgi?id=55500
Alexey Proskuryakov
I don't see any related changes in r80050-r80060. I suspect that the test has been always failing on WebKit2 (it's been landed in r80036).
Michael Nordman
(In reply to comment #4)
> I suspect that the test has been always failing on WebKit2 (it's been landed in r80036).
Seems likely.
If timing is changed under WebKit2 such that the appcache must be loaded from storage instead of still being live in memory, it would fail in this way. Or the cache resides in storage from a previous test run and is loaded from disk instead of being newly created, it would fail in this way.