Closed Bug 1023969 Opened 10 years ago Closed 10 years ago

Change usages of nsCxPusher, AutoCxPusher and AutoPushJSContext to AutoJSAPI and derivatives for bug 951991 - batch 6 ... Bluetooth's Revenge

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla33

People

(Reporter: bobowen, Assigned: bobowen)

References

Details

Attachments

(7 files, 2 obsolete files)

2.23 KB, patch
bholley
: review+
Details | Diff | Splinter Review
2.84 KB, patch
bholley
: review+
Details | Diff | Splinter Review
2.21 KB, patch
bholley
: review+
Details | Diff | Splinter Review
2.57 KB, patch
bholley
: review+
Details | Diff | Splinter Review
2.21 KB, patch
bholley
: review+
Details | Diff | Splinter Review
2.85 KB, patch
bholley
: review+
Details | Diff | Splinter Review
2.59 KB, patch
bholley
: review+
Details | Diff | Splinter Review
Another batch of patches moving nsCxPusher, AutoCxPusher and AutoPushJSContext to AutoJSAPI etc.
See bug 951991 for details.
I don't think that nsTArrayToJSArray needs anything more than an AutoJSAPI.
The JS_SetElement in it is on a new array, so I don't think that can cause problems and I don't think JS_FreezeObject can cause script to be run.
Also, the only errors would be OOM, I believe.

I've put the null check on |mAdapterPtr->GetOwner()| to the start of the function as BluetoothDevice::Create will assert if it is null and there is a similar check in BluetoothManager (see Part 3 to be added shortly).
Attachment #8439310 - Flags: review?(bobbyholley)
This is pretty similar to the part 1.

I added a file scope function to get the Global JS Object.

I seem to have written this code (or what could have and perhaps should have been this code) a number of times for EventTargets.
I was wondering if it would be worth adding the following to DOMEventTargetHelper.h:

JSObject* GetGlobalJSObjectForEventHandlers() const {
  return mOwnerWindow ? static_cast<nsGlobalWindow*>(mOwnerWindow)->GetWrapperPreserveColor()
                      : nullptr;
}

or maybe even add it to nsIDOMEventTarget.idl
Attachment #8439319 - Flags: review?(bobbyholley)
Comment on attachment 8439319 [details] [diff] [review]
Part 2: Replace |AutoPushJSContext|s in BluetoothAdapter::SetPropertyByValue v1

I've got compile issues on B2G try push so I'll cancel for now.
Attachment #8439319 - Flags: review?(bobbyholley)
Attachment #8439310 - Flags: review?(bobbyholley)
Hmm, seems like try is still a bit the worse for wear.

What do you think about the idea, of adding something to get the Global JSObject to DOMEventTargetHelper or nsIDOMEventTarget.idl from comment 2?
Flags: needinfo?(bobbyholley)
We have already
JSContextPtr GetJSContextForEventHandlers();
in nsIDOMEventTarget, so perhaps adding similar for global wouldn't be so bad.
(although I still think any use of JSAPI in DOM code is effectively a bug.)
(In reply to Olli Pettay [:smaug] from comment #5)
> We have already
> JSContextPtr GetJSContextForEventHandlers();
> in nsIDOMEventTarget, so perhaps adding similar for global wouldn't be so
> bad.

Yeah, it looks like a lot of existing consumers use this stuff, so having something similar for the global would reduce the impedence mismatch of switching away from JSContexts.

> (although I still think any use of JSAPI in DOM code is effectively a bug.)

What would your ideal API look like here?
Flags: needinfo?(bobbyholley)
Depends on: 1025476
Now that bug 1025476 is well on its way, I'll crack on with these patches.

I don't think that nsTArrayToJSArray needs anything more than an AutoJSAPI.
The JS_SetElement in it is on a new array, so I don't think that can cause problems and I don't think JS_FreezeObject can cause script to be run.
Also, the only errors would be OOM, I believe.
Attachment #8442979 - Flags: review?(bobbyholley)
Attachment #8439310 - Attachment is obsolete: true
Attachment #8442979 - Flags: review?(bobbyholley) → review+
Wow, that was quick.

These are almost exactly the same as Part 1.
Attachment #8442984 - Flags: review?(bobbyholley)
Attachment #8439319 - Attachment is obsolete: true
Just a WrapNative here, which we've already decided just needs the relevant compartment.

All the other Bluetooth instances are very similar to Parts 1 - 3, so I thought I'd get the OK for these first.

Try push:
https://tbpl.mozilla.org/?tree=Try&rev=17df26a9a40c
Attachment #8442987 - Flags: review?(bobbyholley)
Attachment #8442984 - Flags: review?(bobbyholley) → review+
Attachment #8442987 - Flags: review?(bobbyholley) → review+
Almost identical to Part 2.
Attachment #8443971 - Flags: review?(bobbyholley)
Identical to Part 1, except for bluetooth2.
Attachment #8443973 - Flags: review?(bobbyholley)
Bluetooth2 version of Part 2.
Attachment #8443974 - Flags: review?(bobbyholley)
Bluetooth2 version of Part 4.
Attachment #8443976 - Flags: review?(bobbyholley)
Try push with all patches on top of patch for bug 1025476:
https://tbpl.mozilla.org/?tree=Try&rev=60210f571268

11 AutoPushJSContexts for the price of 7. :-)
Attachment #8443971 - Flags: review?(bobbyholley) → review+
Attachment #8443973 - Flags: review?(bobbyholley) → review+
Attachment #8443974 - Flags: review?(bobbyholley) → review+
Attachment #8443976 - Flags: review?(bobbyholley) → review+
This can go now that bug 1025476 is in m-c.

Try push from below for easy reference:
https://tbpl.mozilla.org/?tree=Try&rev=60210f571268

Landing in part number order.
Thanks.
Keywords: checkin-needed
See Also: → 1031230
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: