Bug 148615 - http/tests/w3c/dom/nodes/Element-matches.html is flaky
Summary: http/tests/w3c/dom/nodes/Element-matches.html is flaky
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
: 148638 (view as bug list)
Depends on: 148670
Blocks: 148546
  Show dependency treegraph
 
Reported: 2015-08-29 23:46 PDT by Chris Dumez
Modified: 2015-09-02 13:10 PDT (History)
12 users (show)

See Also:


Attachments
Patch (13.79 KB, patch)
2015-08-31 14:17 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (12.16 KB, patch)
2015-09-01 22:10 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (12.15 KB, patch)
2015-09-01 22:19 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2015-08-29 23:46:27 PDT
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?
Comment 1 Chris Dumez 2015-08-29 23:48:10 PDT
I haven't marked the test as flaky yet. For now, I have merely rebaselined it in <https://trac.webkit.org/r189158>.
Comment 2 Chris Dumez 2015-08-30 00:06:13 PDT
(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
Comment 3 Chris Dumez 2015-08-30 00:08:33 PDT
(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>.
Comment 4 Chris Dumez 2015-08-31 13:08:30 PDT
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);
Comment 5 Chris Dumez 2015-08-31 13:53:35 PDT
*** Bug 148638 has been marked as a duplicate of this bug. ***
Comment 6 Chris Dumez 2015-08-31 14:17:33 PDT
Created attachment 260316 [details]
Patch
Comment 7 Ryosuke Niwa 2015-08-31 16:26:50 PDT
Comment on attachment 260316 [details]
Patch

Nice catch!
Comment 8 WebKit Commit Bot 2015-08-31 17:23:04 PDT
Comment on attachment 260316 [details]
Patch

Clearing flags on attachment: 260316

Committed r189198: <http://trac.webkit.org/changeset/189198>
Comment 9 WebKit Commit Bot 2015-08-31 17:23:10 PDT
All reviewed patches have been landed.  Closing bug.
Comment 10 Alexey Proskuryakov 2015-08-31 21:51:07 PDT
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
Comment 11 Chris Dumez 2015-08-31 22:12:08 PDT
(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.
Comment 12 WebKit Commit Bot 2015-08-31 22:21:51 PDT
Re-opened since this is blocked by bug 148670
Comment 13 Chris Dumez 2015-09-01 22:10:33 PDT
Created attachment 260407 [details]
Patch
Comment 14 Chris Dumez 2015-09-01 22:19:15 PDT
Created attachment 260409 [details]
Patch
Comment 15 Chris Dumez 2015-09-02 10:08:20 PDT
Comment on attachment 260409 [details]
Patch

Clearing flags on attachment: 260409

Committed r189252: <http://trac.webkit.org/changeset/189252>
Comment 16 Chris Dumez 2015-09-02 10:08:27 PDT
All reviewed patches have been landed.  Closing bug.
Comment 17 Chris Dumez 2015-09-02 13:10:13 PDT
rdar://problem/22544150