Skip to content

Should #close-a-top-level-traversable set #is-closing? #11853

@vinhill

Description

@vinhill

What is the issue with the HTML Standard?

I'm curious why #close-a-top-level-traversable does not set #is-closing. #definitely-close-a-top-level-traversable ensures the traversable is destroyed after unload. As a consequence, whether window.closed is true during pagehide depends on how close was initiated. Also, specs could end up calling close multiple times.

This seems to be consistent between Chrome, Safari and Firefox. I.e. the following logs true

w = window.open()
w.onpagehide = () => console.log(w.closed)
w.close()

while closing the window via browser UI logs false.

There is a note

The close vs. definitely close separation allows other specifications to call close and have it be a no-op if the top-level traversable is already closing due to JavaScript code calling window.close().

Maybe #is-closing was introduced to guard against specs calling close when window.close() was called, but not against specs calling close multiple times. Then the window.closed behavior would be accidental.


I think it's inconsistent to not set #is-closing. But given it's interoperable probably not worth changing. We could rename #is-closing or add a note.

I just stumbled on this while implementing https://wicg.github.io/document-picture-in-picture in Gecko. The spec invokes close when the PiP is navigated and in our preliminary implementation, window.closed will incorrectly be true during the following pagehide.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions