Bug 228089 - [MacOS wk1] imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener.html is flaky failing
Summary: [MacOS wk1] imported/w3c/web-platform-tests/html/semantics/links/links-create...
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-07-19 14:09 PDT by ayumi_kojima
Modified: 2021-07-19 15:43 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ayumi_kojima 2021-07-19 14:09:13 PDT
imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener.html 

Is flaky failing on MacOS wk1 

History: https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fhtml%2Fsemantics%2Flinks%2Flinks-created-by-a-and-area-elements%2Fhtmlanchorelement_noopener.html

Diff:

========================

--- /Volumes/Data/worker/bigsur-debug-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt
+++ /Volumes/Data/worker/bigsur-debug-tests-wk1/build/layout-test-results/imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-actual.txt
@@ -3,6 +3,6 @@
 PASS Check that rel=noopener with target=_self does a normal load
 PASS Check that rel=noopener with target=_parent does a normal load
 PASS Check that rel=noopener with target=_top does a normal load
-PASS Check that targeting of rel=noopener with a given name reuses an existing window with that name
+FAIL Check that targeting of rel=noopener with a given name reuses an existing window with that name assert_equals: expected object "[object Window]" but got null
 PASS Check that targeting of rel=noopener with a given name reuses an existing subframe with that name

========================

I was able to reproduce the failure on tip-of-tree and on r27971 using run-webkit-tests imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener.html -1 -f -iterations 500 --exit-after-n-failures 2 --exit-after-n-crashes-or-timeouts 2
 
On r279969, the test failed, but I received a different diff:

========================

--- /Volumes/Data/Builds/test-279969/layout-test-results/imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt
+++ /Volumes/Data/Builds/test-279969/layout-test-results/imported/w3c/web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-actual.txt
@@ -1,8 +1,10 @@
+CONSOLE MESSAGE: ReferenceError: Can't find variable: BroadcastChannel
 
+
+Harness Error (FAIL), message = ReferenceError: Can't find variable: BroadcastChannel
 
 PASS Check that rel=noopener with target=_self does a normal load
 PASS Check that rel=noopener with target=_parent does a normal load
 PASS Check that rel=noopener with target=_top does a normal load
-PASS Check that targeting of rel=noopener with a given name reuses an existing window with that name
-PASS Check that targeting of rel=noopener with a given name reuses an existing subframe with that name
+NOTRUN Check that targeting of rel=noopener with a given name reuses an existing window with that name

========================
Comment 1 Radar WebKit Bug Importer 2021-07-19 14:09:50 PDT
<rdar://problem/80801807>
Comment 2 Chris Dumez 2021-07-19 14:22:00 PDT
This test is indeed relying on BroadcastChannel. Prior to my patch that added BroadcastChannel, it was not properly running due to lack of BroadcastChannel support.

When I added support, the test started running and I landed baselines for it. However, it appears the test is flaky.

This is not really an issue with my patch but really an issue with the test (or WebKit not properly supporting what this test is checking).
Comment 3 Chris Dumez 2021-07-19 14:44:17 PDT
(In reply to Chris Dumez from comment #2)
> This test is indeed relying on BroadcastChannel. Prior to my patch that
> added BroadcastChannel, it was not properly running due to lack of
> BroadcastChannel support.
> 
> When I added support, the test started running and I landed baselines for
> it. However, it appears the test is flaky.
> 
> This is not really an issue with my patch but really an issue with the test
> (or WebKit not properly supporting what this test is checking).

w.opener is sometimes null in the message event handler. It is unclear why at this point but this seems to be a navigation with target="foo" issue, not a BroadcastChannel issue.
Comment 4 Chris Dumez 2021-07-19 15:35:59 PDT
Committed r280051 (239786@main): <https://commits.webkit.org/239786@main>
Comment 5 Chris Dumez 2021-07-19 15:43:30 PDT
Marked test as flaky on WK1 via <https://commits.webkit.org/r280051>.

This is not super high priority given that it is not really a regression, merely a test that started running as a recent of us enabling BroadcastChannel, which the test required to run.
Comment 6 Chris Dumez 2021-07-19 15:43:48 PDT
Reopening since the bug wasn't fixed.