Closed Bug 1548625 Opened 2 years ago Closed 2 years ago

Eliminate some explicit ExposeObjectToActiveJS calls


(Core :: DOM: Core & HTML, task)

Not set



Tracking Status
firefox68 --- fixed


(Reporter: bzbarsky, Assigned: bzbarsky)




(2 files)

We have a bunch of these scattered about, and we don't need some of them, as far as I can tell.

The basic premise I am operating under is that once an object is unmarked gray, it will stay not-gray if it's in a RootedObject on the stack or a JSAutoRealm/JSAutoNullableRealm on the stack was initialized with it.

Assignee: nobody → bzbarsky
Type: defect → task

Yeah, all stack references should get marked black.

We store newInnerGlobal in a Rooted, so as long as we expose on all codepaths
that assign to that variable (which with this patch we do, typically via
GetWrapper() calls), there's no need to expose explicitly.

The call in VRFrameData::LazyCreateMatrix is not needed because
aRetval.set(aArray) ends up calling into Heap::get() which does a read barrier
and exposes.

The call in nsXULPrototypeScript::Compile is not needed because initializing
the AutoJSAPI will guarantee that the global of the Realm it enters, which is
what we're examining here, will be exposed.

The call in Promise's CreateNativeHandlerFunction is not needed because the
object being passed in was always just-created into a stack Rooted.

The call in MIDIMessageEvent::GetData is not needed because it's always working
with a just-created object. Also, mData is a Heap, so there will be a read
barrier anyway before anyone gets at the value.

The call in PrototypeDocumentContentSink::ExecuteScript is not needed because
the AutoEntryScript will guarantee that the global of the Realm it enters is
exposed. And the JSAutoRealm is not needed either, because we're in that Realm

Pushed by
part 1.  Get rid of some ExposeObjectToActiveJS calls in nsGlobalWindowOuter.  r=mccr8,jonco
part 2.  Get rid of some ExposeObjectToActiveJS calls in DOM code.  r=mccr8,jonco
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.