http/tests/w3c/dom/nodes/Element-matches.html is flaky: --- /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/http/tests/w3c/dom/nodes/Element-matches-expected.txt +++ /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/http/tests/w3c/dom/nodes/Element-matches-actual.txt @@ -171,7 +171,7 @@ PASS In-document Element.matches: :empty pseudo-class selector, matching all empty elements (with no refNodes): #pseudo-empty :empty PASS In-document Element.matches: :link and :visited pseudo-class selectors, matching a and area elements with href attributes (with no refNodes): #pseudo-link :link, #pseudo-link :visited PASS In-document Element.matches: :link and :visited pseudo-class selectors, matching link elements with href attributes (with no refNodes): #head :link, #head :visited -PASS In-document Element.matches: :target pseudo-class selector, matching the element referenced by the URL fragment identifier (with no refNodes): :target +FAIL In-document Element.matches: :target pseudo-class selector, matching the element referenced by the URL fragment identifier (with no refNodes): :target assert_true: The element #target should match the selector. expected true got false PASS In-document Element.matches: :lang pseudo-class selector, matching inherited language (with no refNodes): #pseudo-lang-div1:lang(en) PASS In-document Element.matches: :lang pseudo-class selector, matching specified language with exact value (with no refNodes): #pseudo-lang-div2:lang(fr) PASS In-document Element.matches: :lang pseudo-class selector, matching specified language with partial value (with no refNodes): #pseudo-lang-div3:lang(en) When the test is run on its own, that check seems to pass. However, when running all the layout tests, the check is failing. This seems to indicate we have a bug in WebCore, possibly related to caching?
I haven't marked the test as flaky yet. For now, I have merely rebaselined it in <https://trac.webkit.org/r189158>.
(In reply to comment #1) > I haven't marked the test as flaky yet. For now, I have merely rebaselined > it in <https://trac.webkit.org/r189158>. Actually, I will have to mark it as flaky because it seems bots give different results: https://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/r189158%20(14158)/http/tests/w3c/dom/nodes/Element-matches-diff.txt
(In reply to comment #2) > (In reply to comment #1) > > I haven't marked the test as flaky yet. For now, I have merely rebaselined > > it in <https://trac.webkit.org/r189158>. > > Actually, I will have to mark it as flaky because it seems bots give > different results: > https://build.webkit.org/results/Apple%20Mavericks%20Debug%20WK2%20(Tests)/ > r189158%20(14158)/http/tests/w3c/dom/nodes/Element-matches-diff.txt Marked as flaky in <http://trac.webkit.org/changeset/189159>.
FrameView::scrollToAnchor() also has logic to delay the scroll until the stylesheets are loaded. Which delays the cssTarget() update on the Document as well: bool FrameView::scrollToAnchor(const String& name) { ASSERT(frame().document()); auto& document = *frame().document(); if (!document.haveStylesheetsLoaded()) { document.setGotoAnchorNeededAfterStylesheetsLoad(true); return false; } document.setGotoAnchorNeededAfterStylesheetsLoad(false); Element* anchorElement = document.findAnchor(name); // Setting to null will clear the current target. document.setCSSTarget(anchorElement);
*** Bug 148638 has been marked as a duplicate of this bug. ***
Created attachment 260316 [details] Patch
Comment on attachment 260316 [details] Patch Nice catch!
Comment on attachment 260316 [details] Patch Clearing flags on attachment: 260316 Committed r189198: <http://trac.webkit.org/changeset/189198>
All reviewed patches have been landed. Closing bug.
This broke http/tests/navigation/anchor-frames-same-origin.html on WebKit1: -PASS document.body.scrollTop > 0 is true +FAIL document.body.scrollTop > 0 should be true. Was false. PASS document.body.scrollLeft == 0 is true PASS successfullyParsed is true
(In reply to comment #10) > This broke http/tests/navigation/anchor-frames-same-origin.html on WebKit1: > > -PASS document.body.scrollTop > 0 is true > +FAIL document.body.scrollTop > 0 should be true. Was false. > PASS document.body.scrollLeft == 0 is true > PASS successfullyParsed is true Hmm, Interesting that the EWS did not see this. I am looking now.
Re-opened since this is blocked by bug 148670
Created attachment 260407 [details] Patch
Created attachment 260409 [details] Patch
Comment on attachment 260409 [details] Patch Clearing flags on attachment: 260409 Committed r189252: <http://trac.webkit.org/changeset/189252>
rdar://problem/22544150