This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
While implementing some of the script settings object pushing for Gecko, we were wondering if Step 8 of [1] ought to have something like: "prepare to run a callback with the script settings object associated with input" added to it before it runs its sub-steps and then something like: "clean up after running a callback"" after they've finished. This would mean that if we end up running scripts in any getters we would be sure to use the correct script settings object. [1] http://www.whatwg.org/specs/web-apps/current-work/#internal-structured-cloning-algorithm
To give a bit more detail - it may be possible to prove from the current spec that the structured clone algorithm is always triggered when there is already script (with a script settings object) on the stack. But it would be much more robust, both from a spec and implementation standpoint, to just define the entry point in terms of the object being cloned, which removes the edge cases and ambiguity.
The way I'm currently working around this is that I preemptively clone stuff the first time I get it, then clone the result again later. The second clone can never call script. This is critical anyway because otherwise you are holding a reference to author data which could be changed arbitrarily later.
bholly, bob: given the problem that would come up if we ever cloned something later, rather than immediately, it'll always be a spec bug if that happens. Given that, what do you think I should do here? Having the spec be more "robust" would really only mean that we wouldn't notice that it was badly buggy, no?
Yeah sorry for the delay here. I've been mulling it over in my (very infrequent) spare cycles. Comment 2 is sort of orthogonal to what I was concerned about here. I'm talking about the cases where the structured clone is initiated with no Script Settings Object active. Stuff like postMessage.bind used to be a problem, but we've now fixed that with the WebIDL callback incumbent script stuff. I also had vague uneasiness about other avenues (say, if there was ever a declarative way to trigger a structured clone), but I think for now all the use cases are covered. So I'm fine to close this bug, and modify the Gecko implementation to simply assert that there's already a script settings object on the stack and use that.
Ok.