Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify Window object's close(), closed, et al #4363

Closed
annevk opened this issue Feb 13, 2019 · 5 comments
Closed

Clarify Window object's close(), closed, et al #4363

annevk opened this issue Feb 13, 2019 · 5 comments
Labels
clarification Standard could be clearer topic: browsing context

Comments

@annevk
Copy link
Member

annevk commented Feb 13, 2019

This came up in #4350. The problem is that these members assume there's always a browsing context. But really, once it's been (synchronously) discarded, it's gone, so there needs to be some kind of null check on a Window object's pointer to one.

(This is probably a somewhat wider problem, but fixing it in pieces seems okay. If adventurous one might also want to investigate which of Window/settings objects/Document/Realm/agent would be the logical place to hold the actual pointer.)
@annevk annevk added clarification Standard could be clearer topic: browsing context labels Feb 13, 2019
annevk added a commit that referenced this issue Feb 14, 2019
@annevk
Make window.name deal with lack of browsing context
496364c 
Tests: web-platform-tests/wpt#15391.

Helps with #4363.
@annevk annevk mentioned this issue Feb 14, 2019
Merged
@annevk
Copy link
Member Author

annevk commented Feb 14, 2019

We should probably explicitly define that Window object's associated browsing context is Window object's associated Document object's browsing context?

@domenic
Copy link
Member

domenic commented Feb 14, 2019

once it's been (synchronously) discarded, it's gone

Further discussion on that happening in #4366 (comment). Let's centralize the discussion there.

annevk added a commit that referenced this issue Feb 15, 2019
@annevk
Clarify Document and Window's browsing context slot
d478ef4 
Infrastructure for #3846 and #4363.
@annevk annevk mentioned this issue Feb 15, 2019
Merged
@annevk
Copy link
Member Author

annevk commented Feb 15, 2019 •
edited
Loading

I'm going to leave a comment here since it doesn't seem relevant for the PR per se. Other places that have this problem and I haven't fixed drive-by in #4368:

  • document-tree child browsing context name property set
  • referrer policy
  • windowproxy-getownproperty (this might be okay as I fixed "number of document-tree ...")
  • URL and history update steps
  • concept-location-ancestor-origins-list

annevk added a commit that referenced this issue Feb 19, 2019
@annevk
Clarify Document and Window's browsing contexts
4fe0ac1 
Previously, a Document could sometimes "have no browsing context". Now,
"a Document's browsing context" is either a browsing context or null.

Previously, "a Window's browsing context" was not defined, despite being
referenced extensively. Now, it is defined to be the Window's associated
Document's browsing context.

Related to #3846, #4363, and #4366.
annevk added a commit that referenced this issue Feb 19, 2019
@annevk
Make window.name deal with lack of browsing context
c07b4b7 
Tests: web-platform-tests/wpt#15391.

Helps with #4363.
annevk added a commit that referenced this issue Feb 19, 2019
@annevk
Make window.name deal with lack of browsing context
b8c084e 
Tests: web-platform-tests/wpt#15391.

Helps with #4363.
annevk added a commit that referenced this issue Feb 19, 2019
@annevk
Clarify Window's focus() and blur()
b8aaa49 
In particular when there's a null browsing context, for #4363.

Tests: web-platform-tests/wpt#15460.
This was referenced Feb 19, 2019
Merged
Open
annevk added a commit that referenced this issue Feb 22, 2019
@annevk
Clarify Window's focus() and blur()
12969e1 
In particular when there's a null browsing context, for #4363.

Tests: web-platform-tests/wpt#15460.
This was referenced Feb 26, 2019
Closed
Merged
@annevk
Copy link
Member Author

annevk commented Mar 1, 2019 •
edited
Loading

I looked into named getters on Window and a bit on Document, in particular around the difference when the Window's browsing context becomes null. For Window:

  1. Firefox/Safari stop returning nested browsing contexts (as expected), but continue to return img elements (and presumably the others).
  2. Chrome stops returning anything.

For Document:

  1. Firefox does not support <iframe name>
  2. Chrome/Safari match the spec, but it's surprising in that a Window object reference becomes a HTMLIframeElement reference after the browsing context goes away.

So for Document Firefox probably needs to fix, for Window I'm not sure. Chrome's behavior doesn't really have any particular advantage. Arguably Chrome's behavior is closer to what the specification wants since it talks about the Window's browsing context's active document, rather than the Window's associated document. And the former would no longer be there if the browsing context is null.

[This is now tracked by #4403.]

@annevk annevk mentioned this issue Mar 1, 2019
Closed
annevk added a commit that referenced this issue Mar 4, 2019
@annevk
Make window.window/frames/self deal with no browsing context
0c15092 
Tests: ...

Helps with #4363.
@annevk annevk mentioned this issue Mar 4, 2019
Merged
annevk added a commit that referenced this issue Mar 7, 2019
@annevk
Make window.window/frames/self deal with no browsing context
2938b37 
Tests: ...

Helps with #4363.
annevk added a commit that referenced this issue Mar 7, 2019
@annevk
Fix Window's close(d) members
37b1ce5 
close() needed to queue a task to close, though closed needs to immediately know when close() is invoked too.

Tests: web-platform-tests/wpt#15561 & web-platform-tests/wpt#15649.

Fixes #4405. Helps with #4363.
annevk added a commit that referenced this issue Mar 7, 2019
@annevk
Make window.window/frames/self deal with no browsing context
5e12e95 
Tests: ...

Helps with #4363.
@annevk
Copy link
Member Author

annevk commented Mar 22, 2019

I'm going to close this as the obvious issues have been addressed. If similar issues arise or are identified they should now have a clear resolution path.

@annevk annevk closed this as completed Mar 22, 2019
@annevk annevk mentioned this issue Mar 22, 2019
Closed
annevk added a commit that referenced this issue Oct 2, 2019
@annevk
Make window.window/frames/self deal with no browsing context
e9f6d61 
Language from tc39/ecma262#702.

Tests: web-platform-tests/wpt#15720.

Helps with #4363.
annevk added a commit that referenced this issue Oct 16, 2019
@annevk
Make window.window/frames/self deal with no browsing context
89b7e23 
Before this change these getters did not account for Window object's browsing context potentially being null, resulting in a conceptual crash.

Language from tc39/ecma262#702.

Tests: web-platform-tests/wpt#15720.

Helps with #4363.
zcorpan pushed a commit that referenced this issue Nov 6, 2019
@annevk @zcorpan
Make window.window/frames/self deal with no browsing context
efe6b9b 
Before this change these getters did not account for Window object's browsing context potentially being null, resulting in a conceptual crash.

Language from tc39/ecma262#702.

Tests: web-platform-tests/wpt#15720.

Helps with #4363.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
clarification Standard could be clearer topic: browsing context
Milestone
No milestone
Development

No branches or pull requests
2 participants
@domenic @annevk