Bug 85522

Summary: http/tests/security/sandboxed-iframe-invalid.html is flaky on Mac
Product: WebKit Reporter: Filip Pizlo <fpizlo>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ap, commit-queue, fpizlo, japhet, mkwst, ossy, patrik.j.persson, roger_fong, simon.fraser
Priority: P2 Keywords: LayoutTestFailure
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: All   
Bug Depends on: 102391    
Bug Blocks:    
Attachments:
Description Flags
proposed fix none

Filip Pizlo
Reported 2012-05-03 11:38:14 PDT
I will skip it for now.
Attachments
proposed fix (7.30 KB, patch)
2013-08-12 17:34 PDT, Alexey Proskuryakov
no flags
Alexey Proskuryakov
Comment 1 2012-05-03 15:55:36 PDT
Could you please post a failure diff?
Simon Fraser (smfr)
Comment 2 2012-09-19 16:38:50 PDT
--- /Volumes/SSData/Development/OSX/webkit/OpenSource/WebKitBuild/Debug/layout-test-results/http/tests/security/sandboxed-iframe-modify-self-expected.txt +++ /Volumes/SSData/Development/OSX/webkit/OpenSource/WebKitBuild/Debug/layout-test-results/http/tests/security/sandboxed-iframe-modify-self-actual.txt @@ -1,3 +1,5 @@ +CONSOLE MESSAGE: Unsafe JavaScript attempt to initiate a navigation change for frame with URL http://127.0.0.1:8000/security/sandboxed-iframe-form-top.html from frame with URL http://127.0.0.1:8000/security/resources/sandboxed-iframe-form-top.html. + CONSOLE MESSAGE: Sandbox access violation: Unsafe JavaScript attempt to access frame with URL http://127.0.0.1:8000/security/sandboxed-iframe-modify-self.html from frame with URL http://127.0.0.1:8000/security/resources/sandboxed-iframe-modify-self.html. The frame requesting access is sandboxed into a unique origin. This is a "sanity" test case to verify that a sandboxed frame cannot break out of its sandbox by modifying its own sandbox attribute. Two attempts are made:
Roger Fong
Comment 3 2012-09-24 14:27:45 PDT
This test "passes" on windows bots, but in fact the extra Console output appears on the next test that gets run (script-crossorigin-loads-same-origin.html). Here's the diff of the failing test: --- /home/buildbot/slave/win-release-tests/build/layout-test-results/http/tests/security/script-crossorigin-loads-same-origin-expected.txt 2012-09-21 19:20:20.676828600 -0700 +++ /home/buildbot/slave/win-release-tests/build/layout-test-results/http/tests/security/script-crossorigin-loads-same-origin-actual.txt 2012-09-21 19:20:20.674828500 -0700 @@ -1,3 +1,5 @@ +CONSOLE MESSAGE: Unsafe JavaScript attempt to initiate a navigation change for frame with URL http://127.0.0.1:8000/security/sandboxed-iframe-form-top.html from frame with URL http://127.0.0.1:8000/security/resources/sandboxed-iframe-form-top.html. + Test that a script element with a crossorigin attribute loads same-origin scripts correctly when there's no access control headers in the response. PASS Crazy right? Anyways, I'm skipping this test on Windows to get the other one to pass.
Roger Fong
Comment 4 2012-09-24 14:30:20 PDT
(In reply to comment #3) > This test "passes" on windows bots, but in fact the extra Console output appears on the next test that gets run (script-crossorigin-loads-same-origin.html). > > Here's the diff of the failing test: > --- /home/buildbot/slave/win-release-tests/build/layout-test-results/http/tests/security/script-crossorigin-loads-same-origin-expected.txt 2012-09-21 19:20:20.676828600 -0700 > +++ /home/buildbot/slave/win-release-tests/build/layout-test-results/http/tests/security/script-crossorigin-loads-same-origin-actual.txt 2012-09-21 19:20:20.674828500 -0700 > @@ -1,3 +1,5 @@ > +CONSOLE MESSAGE: Unsafe JavaScript attempt to initiate a navigation change for frame with URL http://127.0.0.1:8000/security/sandboxed-iframe-form-top.html from frame with URL http://127.0.0.1:8000/security/resources/sandboxed-iframe-form-top.html. > + > Test that a script element with a crossorigin attribute loads same-origin scripts correctly when there's no access control headers in the response. > > PASS > > Crazy right? Anyways, I'm skipping this test on Windows to get the other one to pass. O my, posted in the wrong bug... ignore all that.
Mike West
Comment 5 2012-11-16 04:21:29 PST
The root cause here seems to be the previous test: http/tests/security/sandboxed-iframe-form-top.html, which is leaking state into the next test, whatever that happens to be. I've skipped that test in r134929 and r134789 and reneabled the previously skipped tests.
Mike West
Comment 6 2012-12-28 08:32:46 PST
*** Bug 105819 has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 7 2013-08-12 15:29:01 PDT
http/tests/security/sandboxed-iframe-form-top.html got unskipped in r150558 accidentally, so it's causing badness again. I'll see if I can easily fix it, and will skip again if not.
Alexey Proskuryakov
Comment 8 2013-08-12 17:34:44 PDT
Created attachment 208575 [details] proposed fix
WebKit Commit Bot
Comment 9 2013-08-12 20:43:47 PDT
Comment on attachment 208575 [details] proposed fix Clearing flags on attachment: 208575 Committed r153973: <http://trac.webkit.org/changeset/153973>
WebKit Commit Bot
Comment 10 2013-08-12 20:43:50 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.