-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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.
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
Continue to attempt to clarify the reference graph for browsing contexts/Documents/Windows/WindowProxys #2126
Comments
The matching servo issue is servo/servo#14434, since we're trying to follow the spec for this. |
A bit tangential, but I noticed that <script>
function f() {
var w = window.open();
console.log('New window? ', w != window);
w.document.body.appendChild(w.document.createElement('iframe'));
console.log('Got subframe? ', w.length > 0)
var subframe = w[0];
w.close();
console.log('New window is closed? ', w.closed);
console.log('New window\'s subframe is closed? ', subframe.closed);
}
</script>
<a onclick="f()">Click</a> In Firefox and Chrome, the output is:
But in Edge, the output is:
|
Do you also want to better define the concept that holds a collection of browsing contexts (and their event loop)? We haven't really defined that either and I think it would help if we did with name targeting and such and whether or not globals can reach each other. |
I wasn't planning on tackling that as part of this, but who knows what will happen when I start pulling on the threads here. The intent is mainly to clarify the reference graph, not to give names to all concepts. |
@domenic When you said 'As a stretch goal, make "discarding" mean "nobody has any references to it" or maybe "nobody but author code has any references to it", to match its intuitive meaning,' this seems to imply that a |
Mostly as a note to my future self... https://html.spec.whatwg.org/multipage/browsers.html#the-session-history-of-browsing-contexts the first note says:
this is how a Document can be discarded without its browsing context being discarded. |
IRC chat with @domenic: http://logs.glob.uno/?c=freenode%23whatwg&s=20+Dec+2016&e=20+Dec+2016#c1015135. TL;DR: a browser is allowed to discard a document even if script has a reference to it. |
I don't think that is true. What would that mean for the script reference? |
The thing is, "discarded" is a term of art in the spec; it doesn't mean "discarded" in the sense of "garbage collected" or similar. It just means that a certain algorithm, "discard the document", runs. And I think per spec it's totally fine for the "discard the document" algorithm to run even if there's a script reference to the document. That mismatch between our usual use of the word "discarded" and the spec's is what I alluded to in the OP with
|
This makes several changes: * Stop throwing an exception in <a> and <area> activation behavior as a result of popup blocking as it doesn’t match implementations. Fixes #2616. Formal testing is not possible and tracked by web-platform-tests/wpt#3867. * Make matching for special names ASCII case-insensitive. Fixes #2443. * Centralize all user-configurable behavior instead of having it duplicated in various ways in all the caller algorithms. * Call out a known issue with browsing context name matching: #2126. It also modernizes the writing style and makes variables and what is returned much more explicit, including no longer relying on some out-of-band channel for communicating whether a new browsing context got created.
This makes several changes: * Stop throwing an exception in <a> and <area> activation behavior as a result of popup blocking as it doesn’t match implementations. Fixes web-platform-tests/wpt#3867. * Make matching for special names ASCII case-insensitive. Fixes #2443. * Centralize all user-configurable behavior instead of having it duplicated in various ways in all the caller algorithms. * Call out a known issue with browsing context name matching: #2126. It also modernizes the writing style and makes variables and what is returned much more explicit, including no longer relying on some out-of-band channel for communicating whether a new browsing context got created.
#1440 is the browsing context name issue I was after above. It also has ideas how to revamp unit of related browsing contexts into a more imperative construct. |
This makes several changes: * Stop throwing an exception in <a> and <area> activation behavior as a result of popup blocking as it doesn’t match implementations. Fixes web-platform-tests/wpt#3867. * Make matching for special names ASCII case-insensitive. Fixes #2443. * Centralize all user-configurable behavior instead of having it duplicated in various ways in all the caller algorithms. * Call out a known issue with browsing context name matching: #2126. It also modernizes the writing style and makes variables and what is returned much more explicit, including no longer relying on some out-of-band channel for communicating whether a new browsing context got created.
Previously: 39118df; related: #1336. Raised by @asajeffrey in #whatwg; see logs. Probably also want to solve #1930 as part of this.
I think the ideal setup would be:
<dfn>
ed terms for each ownership relationship. The current "associatedDocument
" term is an example of this done well. Issue Document object's Window object #1930 is a case of it done poorly. A diagram would be helpful.This is also vaguely related to #1454, especially the comments about how the spec currently keeps browsing contexts alive for a long time as part of the browsing context tree it uses to track history, whereas implementations have a separate tree. Maybe we'll have to solve that at the same time.
The text was updated successfully, but these errors were encountered: