1620714 - the-window-object/closed-attribute.window.js.ini WPT FAIL with Fission

Status: RESOLVED FIXED

(Core :: DOM: Window and Location, defect, P2)

Description

[Chris Peterson [:cpeterson]]

https://searchfox.org/mozilla-central/source/testing/web-platform/meta/html/browsers/the-window-object/closed-attribute.window.js.ini

if fission: FAIL

Comment 1

[Chris Peterson [:cpeterson]]

The DOM Fission team is relying on feature teams to debug and fix Fission failures in their tests. If the failure looks like a bug in Fission's DOM or IPC changes, you can send the bug back to me.

We're hoping to enable Fission for a subset of Nightly users in early Q3, so we would like WPT tests to be green for Fission by end of Q2. Whether a particular test failure actually blocks shipping Fission is up to the discretion of the feature team. You all would know better than the DOM Fission which test failures are most important.

You can enable Fission when running WPT tests locally using mach wpt --enable-fission.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:kmag, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[u608768]

This is a little odd because it works fine for the cross-origin case (http://www1.web-platform.test:8000), but not for the cross-site case (http://not-web-platform.test:8000).

Based on some brief logging, it looks like we're not going through PContent for the cross-origin case (so the window is in-process? ...but we're dealing with a cross-origin window? What's going on here?), but we are for the cross-site case. And then since we don't wait for an unload/beforeunload before checking the closed property, we check it too soon and we see an unexpected value (since the window isn't closed yet). So I guess my initial hypothesis is that this is a timing thing. I might be missing something.

(just for completeness, the parent window is at http://web-platform.test:8000, and it's the second test case that's failing)

Comment 4

[u608768]

Adding a timeout with t.step_timeout before checking the value of closed seems to fix things, but that's probably not something we want to do. Unless I'm missing some other underlying issue, I think we'll want the closed.html window to tell its opener when it's about to be unloaded and only proceed with the closed checks after we've seen that message.

Comment 5

[Andrew McCreight [:mccr8]]

Assigning to Kashav because he's started looking into this.

Comment 6

[Chris Peterson [:cpeterson]]

Tracking WPT Fission bugs for Fission M6b (Q2)

Comment 7

[u608768]

Attachment: window.html

Comment 8

[u608768]

(In reply to :kashav from comment #3)

This is a little odd because it works fine for the cross-origin case (http://www1.web-platform.test:8000), but not for the cross-site case (http://not-web-platform.test:8000).

The cross-origin window is fission-same-origin (ie, same eTLD+1) as its opener, so that isn't actually a problem. We set nsGlobalWindowOuter::mIsClosed synchronously and content sees the correct window.closed value as soon as the window is actually closed, as expected.

For the remote window (the "cross-site" case), we update BrowsingContext::Closed asynchronously, so we don't see the correct window.closed value immediately. This differs from Chrome's behavior, so we'll probably have to start setting it synchronously.

I have a simpler test case at https://kashav.ca/bugs/1620714.

Comment 9

[u608768]

Attachment: Bug 1620714 - Set BrowsingContext::Closed as early as possible, r?nika

Comment 10

[u608768]

Attachment: Bug 1620714 - Remove fission fail expectation, r?nika

Depends on D77109

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/08b6252d56c8
Set BrowsingContext::Closed as early as possible, r=nika
https://hg.mozilla.org/integration/autoland/rev/f4f86253cc65
Remove fission fail expectation, r=nika

Comment 12

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/08b6252d56c8
https://hg.mozilla.org/mozilla-central/rev/f4f86253cc65

Comment 13

[Henri Sivonen (:hsivonen) (not reading bugmail until 2026-07-27)]

Curiously, dom/base/test/test_window_cross_origin_props.html specifically tests that .close() doesn't synchronously cause .closed to be true, and the test passes in the non-Fission case, but the change made here makes those assertions fail in the Fission case. (The test was disabled for Fission when the change here landed.)

peterv (in the capacity of having reviewed the test case) and annevk (in the capacity of having authored the newer test here), do we actually still want what dom/base/test/test_window_cross_origin_props.html expects regarding .closed?

Comment 14

[Anne (:annevk)]

Apparently I tested and clarified the HTML Standard around close() last year. From the paper trail there a bug against Safari was filed for not updating closed directly and that got fixed. I also filed bug 1533416 on window.open() having a nested event loop being observable. (I see no mention of Chrome and Firefox being different or failing any other tests so I suspect they were aligned already.)

Now, it seems to me that dom/base/test/test_window_cross_origin_props.html invokes close() on a Window that is not script-closable, in particular on one in a child browsing context (unless frames[0] is redefined somewhere, but that does not appear to be case). In those cases close() is supposed to no-op and closed would indeed continue to return false.

Hope that helps.

Comment 15

[Henri Sivonen (:hsivonen) (not reading bugmail until 2026-07-27)]

Thanks. Filed bug 1662103.