[Bug 24403] WebIDL callbacks should probably default to pushing a new entry settings object


--- Comment #2 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Boris Zbarsky from comment #0)
> Looks like we set up incumbent settings objects here, but not entry ones. 

IIUC we do, it's just in HTML5 rather than WebIDL (step 3 of 'prepare to run a
callback'. I've always been a bit fuzzy about how that interacted with the
WebIDL bits though.

> We need to do the latter in various case.  For example, event dispatch
> certainly needs to do it; otherwise you end up running event listeners with
> no entry settings object, but various other specs depend on having an entry
> settings object.

Yeah. The more interesting question is what happens with synchronous event
dispatch and treewalker callbacks. Hixie and I discussed this in SF, and IIRC
he was more or less open to whatever.

I think the sanest definition of "candidate entry settings object" would be to
apply it whenever content script is invoked by the UA (rather than by other
content script), which would align with doing it in all WebIDL callacks. It
remains to be seen whether this is web compatible, though.

> I believe the simplest thing to do here is to always set the entry settings
> object to the global of the callback object (which is NOT the same thing as
> the global of the function getting called, for what it's worth).

Hm. This is different than my current understanding of the spec, and what Gecko
does - both use the global of the function getting called (I think).

However, it's a little bit silly, because per spec today we always follow the
candidate entry settings object (based on the global of the callee) with
another (non-candidate) settings object based on the global of the callback
object. It might make sense to align them.

You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 27 January 2014 06:05:15 UTC