Some ad scripts are wreaking havoc on WebKit sessions states by setting iframe "name" attributes to >100kB of JavaScript. These frames then get some subframes inserted, and we generate absolutely filthy unique names for these subframes.
Created attachment 262597 [details] Patch for EWS Let's see what EWS thinks of this.
Comment on attachment 262597 [details] Patch for EWS Attachment 262597 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/254020 Number of test failures exceeded the failure limit.
Created attachment 262600 [details] Archive of layout-test-results from ews103 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-mavericks Platform: Mac OS X 10.9.5
Comment on attachment 262597 [details] Patch for EWS Attachment 262597 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/254021 Number of test failures exceeded the failure limit.
Created attachment 262601 [details] Archive of layout-test-results from ews106 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Created attachment 262605 [details] Patch for EWS 2 Oh wow. Let's try to avoid a rebaselining nightmare by staying more faithful to the original format.
Comment on attachment 262605 [details] Patch for EWS 2 Attachment 262605 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/254265 New failing tests: http/tests/security/dataURL/xss-DENIED-to-data-url-sub-frame-2-level.html http/tests/security/javascriptURL/xss-ALLOWED-from-javascript-url-to-javscript-url.html http/tests/security/dataURL/xss-DENIED-from-data-url-sub-frame-2-level.html fast/forms/form-and-frame-interaction-retains-values.html http/tests/security/javascriptURL/xss-ALLOWED-to-javascript-url-from-javscript-url.html http/tests/security/javascriptURL/xss-ALLOWED-from-javascript-url-sub-frame-2-level.html http/tests/navigation/image-load-in-subframe-unload-handler.html
Created attachment 262606 [details] Archive of layout-test-results from ews104 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Comment on attachment 262605 [details] Patch for EWS 2 Attachment 262605 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/254288 New failing tests: http/tests/security/dataURL/xss-DENIED-to-data-url-sub-frame-2-level.html http/tests/security/javascriptURL/xss-ALLOWED-from-javascript-url-to-javscript-url.html http/tests/security/dataURL/xss-DENIED-from-data-url-sub-frame-2-level.html fast/forms/form-and-frame-interaction-retains-values.html http/tests/security/javascriptURL/xss-ALLOWED-to-javascript-url-from-javscript-url.html http/tests/security/javascriptURL/xss-ALLOWED-from-javascript-url-sub-frame-2-level.html fast/frames/long-names-in-nested-subframes.html http/tests/security/javascriptURL/xss-ALLOWED-to-javascript-url-sub-frame-2-level.html http/tests/navigation/image-load-in-subframe-unload-handler.html
Created attachment 262609 [details] Archive of layout-test-results from ews101 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 262629 [details] Patch
Comment on attachment 262629 [details] Patch Attachment 262629 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/255079 New failing tests: http/tests/security/javascriptURL/xss-ALLOWED-to-javascript-url-sub-frame-2-level.html
Created attachment 262635 [details] Archive of layout-test-results from ews103 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 262636 [details] Patch
Comment on attachment 262636 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=262636&action=review > Source/WebCore/page/FrameTree.cpp:94 > + unsigned index = 0; > + for (Frame* frame = m_parent->tree().firstChild(); frame; frame = frame->tree().nextSibling()) { > + if (&frame->tree() == this) > + return index; > + ++index; > + } I would have walked backwards from this looking for null instead. Not sure why. > Source/WebCore/page/FrameTree.cpp:178 > + name.appendNumber(frame->tree().indexInParent()); Is there any N^2 problem with walking the frames to compute the index?
(In reply to comment #15) > Comment on attachment 262636 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=262636&action=review > > > Source/WebCore/page/FrameTree.cpp:94 > > + unsigned index = 0; > > + for (Frame* frame = m_parent->tree().firstChild(); frame; frame = frame->tree().nextSibling()) { > > + if (&frame->tree() == this) > > + return index; > > + ++index; > > + } > > I would have walked backwards from this looking for null instead. Not sure > why. k :) > > Source/WebCore/page/FrameTree.cpp:178 > > + name.appendNumber(frame->tree().indexInParent()); > > Is there any N^2 problem with walking the frames to compute the index? I doubt there is a problem in practice, since trees rarely have more than 1 or 2 frames per "level of ancestry." If you think it could be a real problem, we could track in-parent indices on FrameTree. FrameTree only supports append and remove operations for children, so it wouldn't be too difficult to track.
Comment on attachment 262636 [details] Patch Clearing flags on attachment: 262636 Committed r190752: <http://trac.webkit.org/changeset/190752>
All reviewed patches have been landed. Closing bug.