Unclear distinction between "entry" and "incumbent" settings objects

[jyasskin]

The incumbent settings object is the top entry in the stack of script settings objects, and the entry settings object is the top entry that's marked as a candidate entry settings object. However, I only see one place that pushes an entry onto the stack, and it marks it as a candidate.

Maybe we can eliminate one of the terms?

If not, it'd be good for other spec authors if HTML mentioned how these two terms differ, and how we should choose between them.

[annevk]

Yeah it would. See also:

• https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=27203

Unfortunately this is an area that's not well understood, so I don't expect this to be addressed real soon, but it's one of the things I'd like to solve if nobody beats me to it.

[jyasskin]

Do you have an intuitive understanding of the intended difference between the terms, that you could write down here? I have no idea, so I've been picking randomly based on the last spec I read, and I could do better with even a sketch of the difference.

[bzbarsky]

The entry settings object is where script was first entered.

The incumbent settings object is what script was running when the call into the IDL-defined interface happened.

So a simple example. A.html has:

<iframe src="B.html"></iframe>
<script>onload = function() { frames[0].foo(); }</script>

B.html has:

<script>function foo() { someDOMObject.doSomething() }</script>

When the call to doSomething happens the entry settings object is the one for A.html and the incumbent settings object is for B.html.

It's also not true that only one place pushes an entry onto the stack. Right below the place you link to, there is:

When a JavaScript SourceElements production is to be evaluated, the settings object of the script corresponding to that SourceElements must be pushed onto the stack of script settings objects before the evaluation begins, and popped when the evaluation ends (regardless of whether it's an abrupt completion or not).

The problem, of course, is that SourceElements is an ES5 grammatical concept (it's the production for a function body or toplevel script in ES5). The intent is that any time a toplevel script is executed or a function is called, the corresponding incumbent settings object goes on the stack.

It would be better if this were defined in terms of ES6. Probably in terms of EvaluateBody and whatever the toplevel script equivalent is, though maybe it can be done in terms of the "execution context stack" manipulation ES6 performs.... maybe.

[jyasskin]

Thanks, that's very helpful.

[domenic]

Update on this, which I am working on as part of the es-init branch:

• I have confirmed it is not really feasible to try to use the JS execution context stack to track the settings object stack. I am as such adding the following non-normative note: "The stack of script settings objects does not correspond to the
  JavaScript execution context stack. The former is used for tracking transitions
  between different scripts, whereas the latter operates at the lower level of
  (roughly) individual JavaScript functions."
• I plan to add @bzbarsky's example, alongside the spec's current more complicated one, to try to add clarity. Actually, @bzbarsky's example is basically the same as the one in the spec. I have broken up the explanatory paragraph following it into one about vocabulary and one about location.assign, in the hopes that it will be easier to skim.
• I plan to address the ES5 vs. ES6 impedance mismatch as well.

[domenic]

Dammit, I got this all wrong; I didn't realize SourceElements was basically function bodies. OK, maybe there is a 1:1 correspondence between JS execution context stack and stack of script settings objects after all.

[bzbarsky]

The execution context stack probably needs to be updated when calling a DOM method, but the incumbent script context should not be.

Or to put this in concrete terms, if [[Call]] for Web IDL methods is defined more or less like http://www.ecma-international.org/ecma-262/6.0/#sec-built-in-function-objects-call-thisargument-argumentslist then this testcase:

frames[0].postMessage(/* stuff */)

will have the JS execution context updated to that of frames[0] by the time the actual algorithm steps of postMessage are reached, while the incumbent script settings object needs to be the calling code.

Or to put this in a slightly different way, DOM built-in functions are not considered "different scripts" for purposes of the stack of script settings objects.