WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 85522
http/tests/security/sandboxed-iframe-invalid.html is flaky on Mac
https://bugs.webkit.org/show_bug.cgi?id=85522
Summary
http/tests/security/sandboxed-iframe-invalid.html is flaky on Mac
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
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug