Entry realm definition #2441
Comments
|
I'm pretty confused by this question. Maybe @bzbarsky can help interpret it. It sounds like good fodder for turning into an example though, once I figure out what it's asking. Would you mind trying to rephrase? Perhaps something of the form "X phrase in the definition seems wrong, because Y". |
|
The situation @jensl is worried about is this. Say we have two realm execution contexts, A and B. We do the following operations:
Note us not incrementing the counter on A after step 5. At this point, per the current spec text, A is the entry execution context. But arguably it should be B. We do in fact have one place that pushes a realm execution context on the stack without changing its entrance counter: https://html.spec.whatwg.org/#event-handler-attributes:realm-execution-context. But it just wants to change the current Realm and doesn't at all care what the entry execution context or entry Realm is, so there's no problem there. Which raises the obvious question: do we actually need the entrance counter at all? |
|
Thanks, that definitely helps. Hmm. So the proposal would be to use the most recent execution context that is a Realm execution context? I was looking through #473 where we worked most of this out. It does seem like we just assumed there was some need to tag entries on the stack as being "candidates" for entry-ness, possibly because that was what Hixie specced? We then evolved to the counter idea around #473 (comment). But maybe just being a realm execution context is enough, since we push/pop those at exactly the right times... |
|
I think the "entryness" was needed back when incumbents were tracked using the same stack. |
|
Thank you both for replies and explanations. Based on what you say, it sounds to me like the entrance counter is probably unnecessary, and that the top-most realm execution context on the stack would be the right one to use regardless. |
It turns out that the "entrance counter" concept was unnecessary. Whenever we run script, we increment it, and whenever we clean up after running script, we decrement it. So it is always nonzero. Thus we can simply look for whether it's a realm execution context. Fixes #2441.
It turns out that the "entrance counter" concept was unnecessary. Whenever we run script, we increment it, and whenever we clean up after running script, we decrement it. So it is always nonzero. Thus we can simply look for whether it's a realm execution context. Fixes #2441.
It turns out that the "entrance counter" concept was unnecessary. Whenever we run script, we increment it, and whenever we clean up after running script, we decrement it. So it is always nonzero. Thus we can simply look for whether it's a realm execution context. Fixes whatwg#2441.
It turns out that the "entrance counter" concept was unnecessary. Whenever we run script, we increment it, and whenever we clean up after running script, we decrement it. So it is always nonzero. Thus we can simply look for whether it's a realm execution context. Fixes whatwg#2441.
It turns out that the "entrance counter" concept was unnecessary. Whenever we run script, we increment it, and whenever we clean up after running script, we decrement it. So it is always nonzero. Thus we can simply look for whether it's a realm execution context. Fixes whatwg#2441.
https://html.spec.whatwg.org/#entry
Is there some way that an execution context that has an entrance counter greater than zero from before can be pushed onto the JavaScript execution context stack without an "accompanying" entrance counter increment, and thus at that point become the current entry execution context without being explicitly "entered"?
I'm inclined to think that this should not happen; that entry realm changes should only happen at the points where the entrance counter is now incremented/decremented, effectively. So I think one of these things are wrong:
The text was updated successfully, but these errors were encountered: