1837302 - Implement an opt-in mechanism for WebIDL methods which can synchronously run JS or spin a nested event loop to add logic to (re)throw uncatchable exceptions in the binding with a DEBUG/FUZZING verification that all appropriate bindings are labeled.

Status: NEW

(Core :: DOM: Bindings (WebIDL), enhancement, P3)

Description

[Andrew Sutherland [:asuth] (he/him)]

Web APIs that may synchronously call into JS or spin a syncloop create a situation where an uncatchable exception may be generated by the JS interrupt mechanism inside the nested sync JS dispatch (or where an uncatchable exception would have been generated if JS was on the stack, but because we were sitting in a nested event loop, the global was instead directly marked as dying). In these cases, it is appropriate for the bindings to these calls to (re)throw an uncatchable exception. However, this is an extremely rare situation and so it's not appropriate for every WebIDL binding method wrapper to have logic to handle this situation. Instead, it's appropriate to only generate the logic for those methods where it's a possible situation, but it's also a situation where we can ensure that DEBUG and FUZZING builds verify that we have properly labeled all tested APIs.

When this was originally discussed at the DOM peers meeting a while back, it was not clear whether the annotation should be in WebIDL or in Bindings.conf. My vague hand-waving thoughts were that:

• A Gecko engineer investigating something is much more likely to notice it in the WebIDL and potentially benefit from it than having it in Bindings.conf
• Because this is such a rare situation and it's such a bad idea/design for Web APIs to perform sync JS invocation, having the annotations in WebIDL doesn't create a problem where people copying WebIDL from specs because there should be no new specs that need the annotation. And if there are, all reviewers would benefit from having that be very obvious! (WebIDL reviewers would likely notice a change in Bindings.conf, but others may not.)