In general, using an AutoJSAPI inited with an object is NOT the same as using
AutoSafeJSContext (or AutoJSAPI inited without an object) and then entering the
compartment of the object: the former will report exceptions to the global of
the object as it comes off the stack, while the latter will not. This only
really matters if we have an object from a window or worker global and hence
might fire error events, or report internal stuff to the web console.
The changes to initing with an object made in this bug are OK for the following
reasons:
1) dom/base/Console.cpp: Always clears its exception before coming off the stack.
2) dom/base/nsDOMClassInfo.cpp: Inits with a non-web global.
3) dom/base/nsFrameMessageManager.cpp: Inits with a non-web global.
4) dom/media/MediaPermissionGonk.cpp: We probably want the caller to notice if
anything here throws.
5) dom/xbl/nsXBLPrototypeBinding.cpp: Inits with a non-web global.
6) dom/xul/nsXULElement.cpp: Inits with a non-web global.
7) extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp: Inits with a non-web global.
8) ipc/testshell/XPCShellEnvironment.cpp: Inits with a non-web global.
The AVRCP passthough-command notification doesn't require |int| type
arguments. Using |uint8_t| is sufficient. This change is required to
prepare replacing |nsAutoArrayPtr<>| with |UniquePtr<[]>|.
The use is init and deinit methods is currently inconsistent among
Bluetooth profile managers. This patch unifies all these methods and
integrates them into the Bluetooth service. Instances of the manager
classes are now unref'ed during Bluetooth shutdown.
Bluetooth's UUID arrays are sorted and stripped from duplicates. This code is
now executed in the client process. This reduces the amount of privilegued
code and accounts the required computation time to the process that actually
uses it.
The change also makes the IPDL interface a bit less fragile, as the client
does not expect sorted arrays from the chrome process. It's a detail of the
client's implementation that manifested itself in the interface.
ObexHeaderSet::GetTarget copies the data associated with the
ObexHeaderId::Target id into a newly-allocated buffer. All callers of
this function, however, fail to free the buffer once they are done with it.
Instead of simply freeing the buffer in the caller, however, let's add
an API to ObexHeaderSet that gives direct access to the desired header.
Doing this means that we have direct access to the data--no copying
necessary--and we also make the caller slightly faster, since it no
longer has to verify that the appropriate header is there, followed by
re-searching for the header it already knows is there.
This patch improves the Bluetooth signal API by adding methods for
dealing with UUIDs and addresses directly. Callers have been converted
where possible.