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

Hide ParisBinding's SomeDictionaryInit(JSContext* aCx, ...) from non-autogenerated code?

NEW
Assigned to

Status

()

Core
DOM
5 years ago
5 years ago

People

(Reporter: smaug, Assigned: smaug)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

5 years ago
As far as I see, Init() is a bit error prone. Nothing guarantees correct compartment.
So, might be better to use the current Init only in auto-generated code, and
add another Init for manual use. That new one should enter to the right compartment.

(Of course one shouldn't use Init manually, but not everything is converted to WebIDL yet)
Are we talking about WebIDL dictionaries, or some other Init()?
(Assignee)

Comment 2

5 years ago
Oops :) Dictionaries yes.
Summary: Hide ParisBinding's XXXInit(JSContext* aCx, ...) from non-autogenerated code? → Hide ParisBinding's SomeDictionaryInit(JSContext* aCx, ...) from non-autogenerated code?
OK.

So one problem is that I have no idea how to hide a member like that, short of making it private and making all the generated functions that use it friends...
(Assignee)

Comment 4

5 years ago
What about just naming it InitInternal or some such to hint that it shouldn't be used normally,
and provide safer Init which does the compartment stuff etc.
Ah, we could do that, yes.

That said, the only compartment thing going on is that cx, scopeObj, and val all need to be same-compartment, right?  I guess the concern is C++ consumers that will pass in a wrong-compartment scopeObj?  Or are we worried about cx not matching val too?
So I guess what we could do is enter the compartment of scopeObj (assuming it's non-null) and then JS_WrapValue the val....

Want to write a patch?
(Assignee)

Updated

5 years ago
Assignee: nobody → bugs
You need to log in before you can comment on or make changes to this bug.