If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Expose WebIDL callbacks to JS-implemented WebIDL via C++ objects so we can do the right thing with exceptions and arguments

NEW
Unassigned

Status

()

Core
DOM
4 years ago
4 years ago

People

(Reporter: bz, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

This is akin to what we want to do for them anyway for bug 858741, but this is for functional reasons.

The basic problem with exceptions right now all you can do is call the callback and if it throws catch the exception ... and then what?  You don't want to report it on the chrome jscontext!

What we need are two possible behaviors, corresponding to the behaviors callbacks have in C++ already:

1)  Report the content exception on the content JSContext before returning to
    the chrome JS.
2)  Rethrow the exception to the chrome JS so that it can catch it or rethrow to
    content as desired.

This means that we need a C++ object that chrome js interacts with (presumably codegenned?) that holds the C++ callback pointer and calls into that.

The arguments issue is that if we do the auto-conversion thing in bug 865951 then passing a newly-created JS-implemented thing to a callback will only work if we convert to a C++ object before going out to the content JS.
> You don't want to report it on the chrome jscontext!

Another option here is to just have a way to ask the exception to be reported on whatever the JSContext for the callback is.  Or something.
Yeah, I think we should expose them via a C++ object. This means that we'll piggy-back on the correct behavior that happens in CallSetup, which will be a bit of a moving target as we transition everything to AutoJSAPI/AutoEntryScript in bug 989528.
You need to log in before you can comment on or make changes to this bug.