26544 2014-08-08 14:29:33 +0000 Pushing a script settings object during structured clone. 2014-09-16 17:48:37 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WORKSFORME P3 normal Unsorted 1 bobowencode ian bobbyholley ian mike contributor oldest_to_newest 110040 0 bobowencode 2014-08-08 14:29:33 +0000 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 110046 1 bobbyholley 2014-08-09 03:36:03 +0000 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. 110250 2 ian 2014-08-18 20:35:41 +0000 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. 111556 3 ian 2014-09-15 22:40:48 +0000 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? 111584 4 bobbyholley 2014-09-16 10:29:08 +0000 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. 111608 5 ian 2014-09-16 17:48:37 +0000 Ok.