Popup window is closing before the end of the test in html/semantics/… #30001
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…links/links-created-by-a-and-area-elements/htmlanchorelement_noopener.html In html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener.html, the "Check that targeting of rel=noopener with a given name reuses an existing window with that name" test (t1) opens a popup window via window.open() and then navigates this window to "support/noopener-target-2.html" via link targetting. The issue is that the JS inside noopener-target-2.html sends a BroadcastChannel message and then calls `window.close()` right away. Then htmlanchorelement_noopener.html receives the BroadcastChannel messages, it does the following check: `assert_equals(w.opener, window);`. This check is failing in WebKit because the popup window |w| has already been closed by the time the message is received. The test already takes care of calling `w.close()` as a clean up step so there is actually no need for noopener-target-2.html to call `window.close()` itself.
wpt-pr-bot
requested review from
annevk,
domenic,
foolip,
jdm,
jgraham and
zqzhang
|
Hmm. By my reading of the spec, if you do BroadcastChannel + window.close(), those both post a task on the same task source (the DOM manipulation task source). So they should execute in order; it shouldn't be possible for the window to close before the message is delivered. |
Oh I see, this is likely a bug in the WebKit implementation of BroadcastChannel then. This would explain why the test is passing in Firefox and Chrome. It is a bit tricky because BroadcastChannel allows communication cross-process (and thus involves IPC in WebKit). |
|
Yeah, I'm not sure that part of the spec was written very well from that point of view, so I at least would be open to changing the spec. But maybe if it's working in 2/3 browsers people are depending on it... hard to say. |
webkit-commit-queue
pushed a commit
to WebKit/WebKit
that referenced
this pull request
Sep 16, 2021
…links-created-by-a-and-area-elements/htmlanchorelement_noopener.html is flaky failing https://bugs.webkit.org/show_bug.cgi?id=228089 <rdar://problem/80801807> Reviewed by Darin Adler. LayoutTests/imported/w3c: Rebaseline test that is now consistently passing. * web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt: Source/WebCore: As per the HTML specification, window.close() should schedule a task on the event loop to actually close the window: - https://html.spec.whatwg.org/multipage/window-object.html#dom-window-close We were failing to do so and this was causing flakiness because event ordering was inconsistent. This was discussed on upstream WPT here: - web-platform-tests/wpt#30001 No new tests, unskipped existing test. * page/DOMWindow.cpp: (WebCore::DOMWindow::close): LayoutTests: Unskip test that should no longer be flaky. * platform/ios-wk2/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/mac-wk2/TestExpectations: Canonical link: https://commits.webkit.org/241767@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@282606 268f45cc-cd09-0410-ab3c-d52691b4dbfc
bertogg
pushed a commit
to Igalia/webkit
that referenced
this pull request
Sep 17, 2021
…links-created-by-a-and-area-elements/htmlanchorelement_noopener.html is flaky failing https://bugs.webkit.org/show_bug.cgi?id=228089 <rdar://problem/80801807> Reviewed by Darin Adler. LayoutTests/imported/w3c: Rebaseline test that is now consistently passing. * web-platform-tests/html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener-expected.txt: Source/WebCore: As per the HTML specification, window.close() should schedule a task on the event loop to actually close the window: - https://html.spec.whatwg.org/multipage/window-object.html#dom-window-close We were failing to do so and this was causing flakiness because event ordering was inconsistent. This was discussed on upstream WPT here: - web-platform-tests/wpt#30001 No new tests, unskipped existing test. * page/DOMWindow.cpp: (WebCore::DOMWindow::close): LayoutTests: Unskip test that should no longer be flaky. * platform/ios-wk2/TestExpectations: * platform/mac-wk1/TestExpectations: * platform/mac-wk2/TestExpectations: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@282606 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…links/links-created-by-a-and-area-elements/htmlanchorelement_noopener.html
In html/semantics/links/links-created-by-a-and-area-elements/htmlanchorelement_noopener.html, the "Check that targeting of rel=noopener with
a given name reuses an existing window with that name" test (t1) opens a popup window via window.open() and then navigates this window to
"support/noopener-target-2.html" via link targetting. The issue is that the JS inside noopener-target-2.html sends a BroadcastChannel message
and then calls
window.close()right away. Then htmlanchorelement_noopener.html receives the BroadcastChannel messages, it does the followingcheck:
assert_equals(w.opener, window);. This check is failing in WebKit because the popup window |w| has already been closed by the timethe message is received. The test already takes care of calling
w.close()as a clean up step so there is actually no need fornoopener-target-2.html to call
window.close()itself.