Re: [heycam/webidl] Propagate active script to callbacks (#902)

Yes, I was a bit worried about the runtime costs. I'm glad you think that cost will be OK, but don't hesitate to push back if you think it is too expensive. Although I think this change is a good one, I don't think it's infinitely good; if it has high costs then we should reevaluate.

> I think it's better to notify those who will implement Promise callbacks and WeakRef callbacks of Chromium. They will need to implement not only the incumbent but also the active script.

Yes, @syg is helping with that, and that is actually what prompted this discussion. Currently promises are specced to propagate active script, and they do in Chromium; we were working on generalizing that to WeakRef, but noticed that there was an inconsistency with Web IDL callbacks.

> Q: Is there a case that IDL callback's incumbent's execution context's ScriptOrModule is null?

I think it is never null. By "incumbent's execution context" you probably mean the execution context in step 1 of https://html.spec.whatwg.org/#incumbent-settings-object? In that case then it is definitely never null.

This is very interesting. I guess your idea is that Chromium would store the "topmost script-having execution context" (i.e. "incumbent's execution context") instead of storing the (incumbent settings object, active script) tuple? Then it could infer active settings object using the algorithm in https://html.spec.whatwg.org/#incumbent-settings-object, and active script using the ScriptOrModule component.

I think that works, and means no extra runtime cost. (At least, in spec terms; I am not sure how it maps to Chromium implementation primitives.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/902#issuecomment-657648003