This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
Summary:
DestructValue acts a lot like CleanupValue, however in addition to normal
cleanup work, it invokes the destructor of complex data types. This is important
to ensure that constructors and destructors are matched for these complex data
types.
CleanupValue is also used to clean up a value without destructing it, so cannot
be modified in-place.
Depends On D2689
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2690
Summary:
This macro simplifies code which allows performing an operation on or
extracting information from a particular nsXPTType's native representation.
It is also used in part 2 to implement xpc::DestructValue.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2689
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
In PLDHashTable the equivalent functions have a "Shallow" prefix, which makes
it clear that they don't measure things hanging off the table. This patch makes
mozilla::Hash{Set,Map} do likewise.
MozReview-Commit-ID: 3kwCJynhW7d
--HG--
extra : rebase_source : 9c03d11f376a9fd4cfd5cfcdc0c446c00633b210
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Summary:
This means that using these types involves many fewer footguns, while not
requiring any changes to the actual XPConnect implementation!
Depends on D2111
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2334
Summary:
This should make it more clear which types have which behaviours, and should
make it easier to add new types without forgetting to handle a special case
somewhere.
Depends On D2114
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2115
This will get us both more clarity as to what types are, but also will improve switch exhaustiveness checks.
Summary: Depends On D2113
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2114
Summary:
This patch adds support for the `Sequence<T>` type. This is largely a
straightforward type propagation patch, but there are a few notable things:
1. We allow `[iid_is(x)] Sequence<nsQIResult>`, so Sequence can be Dependent.
2. `Sequence<T>` is reflected into C++ as a `nsTArray<T>`, which is different
than WebIDL's `mozilla::dom::Sequence<T>` type. This decision was made for
general ergonomics reasons, as `nsTArray<T>` is more prevailent throughout
the codebase, and lengths in this case cannot be controlled by content, as
XPConnect is only exposed to Chrome JS.
3. Owned pointers in `Sequence<T>` are not reflected as their owned
counterparts. For example, `Sequence<nsISupports>` is reflected as
`nsTArray<nsISupports*>` rather than `nsTArray<RefPtr<nsISupports>>`. This
was done to avoid depending on `RefPtr<T>` and `T*` having the same
in-memory representation, however if that is considered an acceptable
dependency, it would be nice to support that.
4. We also don't reflect singly-owned pointers as their owned counterparts. For
example, `nsTArray<nsIIDPtr>` would be reflected as `nsTArray<nsIID*>`
rather than `nsTArray<mozilla::UniquePtr<nsIID>>`. If we are willing to
depend on `mozilla::UniquePtr<T>`'s in-memory representation, we could also
do this, however.
5. There are no restrictions on what types can appear inside of a `Sequence<T>`
or what can appear inside an `[array] T`. We may want to add restrictions
either at the xpidl level or in XPConnect.
Depends On D2109
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2110
Summary:
The background logic for handling lists of XPConnect values is similar between
`[array] T` and `Sequence<T>`. The major differences are with regard to how
native length is determined, how 'null' and 'undefined' are handled, and how
native buffer allocation is handled.
This patch modifies the JSArray2Native function to make it generic over an
allocation strategy function, which can be implemented for each of `[array] T`
and `Sequence<T>`. The function takes in a `uint32_t*` pointer, pointing at the
computed length of the JS array. The callback can then allocate the correct
backing buffer, and optionally modify the length to copy.
The NativeArray2JS function is also modified to make it directly take a pointer
to the native buffer rather than determining it from a pointer to an `[array] T`
parameter.
Depends On D2105
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2106
Summary:
A goal of the Sequence<T> work is to allow using more complex types within lists
in XPConnect. For example, we ideally want to support `Sequence<AString>`,
rather than requiring people to use the unergonomic 'wstring' type.
These types require initialization before they can be read into. Currently this
initialization for parameters is directly handled by XPCWrappedNative's
CallMethodHelper object.
This patch introduces a new function to the `xpc` namespace to initialize a
specific value from an uninitialized state to a safe state.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2105
Support for the _xpcom_categories property was removed in Bug 568691,
but we left a bunch of consumers behind, and it's been cargo-culted a bit more.
We should remove the remaining remnants.
Differential Revision: https://phabricator.services.mozilla.com/D2429
--HG--
extra : moz-landing-system : lando
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Summary:
This means that using these types involves many fewer footguns, while not
requiring any changes to the actual XPConnect implementation!
Depends on D2111
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2334
Summary:
This should make it more clear which types have which behaviours, and should
make it easier to add new types without forgetting to handle a special case
somewhere.
Depends On D2114
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2115
This will get us both more clarity as to what types are, but also will improve switch exhaustiveness checks.
Summary: Depends On D2113
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2114
Summary:
This patch adds support for the `Sequence<T>` type. This is largely a
straightforward type propagation patch, but there are a few notable things:
1. We allow `[iid_is(x)] Sequence<nsQIResult>`, so Sequence can be Dependent.
2. `Sequence<T>` is reflected into C++ as a `nsTArray<T>`, which is different
than WebIDL's `mozilla::dom::Sequence<T>` type. This decision was made for
general ergonomics reasons, as `nsTArray<T>` is more prevailent throughout
the codebase, and lengths in this case cannot be controlled by content, as
XPConnect is only exposed to Chrome JS.
3. Owned pointers in `Sequence<T>` are not reflected as their owned
counterparts. For example, `Sequence<nsISupports>` is reflected as
`nsTArray<nsISupports*>` rather than `nsTArray<RefPtr<nsISupports>>`. This
was done to avoid depending on `RefPtr<T>` and `T*` having the same
in-memory representation, however if that is considered an acceptable
dependency, it would be nice to support that.
4. We also don't reflect singly-owned pointers as their owned counterparts. For
example, `nsTArray<nsIIDPtr>` would be reflected as `nsTArray<nsIID*>`
rather than `nsTArray<mozilla::UniquePtr<nsIID>>`. If we are willing to
depend on `mozilla::UniquePtr<T>`'s in-memory representation, we could also
do this, however.
5. There are no restrictions on what types can appear inside of a `Sequence<T>`
or what can appear inside an `[array] T`. We may want to add restrictions
either at the xpidl level or in XPConnect.
Depends On D2109
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2110
Summary:
The background logic for handling lists of XPConnect values is similar between
`[array] T` and `Sequence<T>`. The major differences are with regard to how
native length is determined, how 'null' and 'undefined' are handled, and how
native buffer allocation is handled.
This patch modifies the JSArray2Native function to make it generic over an
allocation strategy function, which can be implemented for each of `[array] T`
and `Sequence<T>`. The function takes in a `uint32_t*` pointer, pointing at the
computed length of the JS array. The callback can then allocate the correct
backing buffer, and optionally modify the length to copy.
The NativeArray2JS function is also modified to make it directly take a pointer
to the native buffer rather than determining it from a pointer to an `[array] T`
parameter.
Depends On D2105
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2106
Summary:
A goal of the Sequence<T> work is to allow using more complex types within lists
in XPConnect. For example, we ideally want to support `Sequence<AString>`,
rather than requiring people to use the unergonomic 'wstring' type.
These types require initialization before they can be read into. Currently this
initialization for parameters is directly handled by XPCWrappedNative's
CallMethodHelper object.
This patch introduces a new function to the `xpc` namespace to initialize a
specific value from an uninitialized state to a safe state.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2105
For ordinary JS helper threads, we can update names and create wrappers using
the existing thread profiler hooks, but we still need to update their default
stack sizes to avoid huge pages.
For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but
only sometimes. And we never use a reasonable stack size.
MozReview-Commit-ID: EuR3gL5JATL
--HG--
extra : rebase_source : 99985a751a37fb8c515cea8cdae4526b319aba67
extra : intermediate-source : 4831cbfd03ded9ea6dcc8d6f0797f5f80fb717c7
extra : source : f092a32a363911e58c71ed5d2e4bd92347437c7e
For ordinary JS helper threads, we can update names and create wrappers using
the existing thread profiler hooks, but we still need to update their default
stack sizes to avoid huge pages.
For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but
only sometimes. And we never use a reasonable stack size.
MozReview-Commit-ID: EuR3gL5JATL
--HG--
extra : source : f092a32a363911e58c71ed5d2e4bd92347437c7e
extra : histedit_source : e66e41015f56882fb94b82244da9da3a8dd15c30
For ordinary JS helper threads, we can update names and create wrappers using
the existing thread profiler hooks, but we still need to update their default
stack sizes to avoid huge pages.
For the XPConnect JS Watchdog thread, we sometimes get a wrapper as it is, but
only sometimes. And we never use a reasonable stack size.
MozReview-Commit-ID: EuR3gL5JATL
--HG--
extra : rebase_source : ccf47a10321d2f859d3a3d93e79ac18bf44b73a8
Wrappers are per-compartment, not per-realm, so this will simplify the next patch. Also, considering the upcoming Realms proposal, it might eventually be possible to have multiple globals in a sandbox compartment.
GetOrCreateMapEntryForPrototype is the only caller where the object could be a CCW. However there cx and proto are same-compartment (GetOrCreateMapEntryForPrototype asserts this) so I changed that code to use JS::CurrentGlobalOrNull.
Created a runtime hook to handle DOM nodes. Specialized ubi::Concrete for nsINode-inheriting objects. Displayed outgoing nsISupports* edges on reflector JSObjects. Generated outgoing child edges from nsINodes by examining their children. Updated the UbiNodeCensus to ignore zone checks if there is no zone to be found in a node.
--HG--
extra : rebase_source : 319dccb3277a39e51a79588eac9c8f2b4ff97c2f
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
Summary:
This is done so we can use Array as the name for the new nsTArray-based
type, rather than having to come up with a new name.
LegacyArray was chosen as the [array] attribute is now effectively deprecated,
and we'd like to remove it ASAP.
Depends On D2334
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2335
Summary:
This means that using these types involves many fewer footguns, while not
requiring any changes to the actual XPConnect implementation!
Depends on D2111
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2334
Summary:
This should make it more clear which types have which behaviours, and should
make it easier to add new types without forgetting to handle a special case
somewhere.
Depends On D2114
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2115
This will get us both more clarity as to what types are, but also will improve switch exhaustiveness checks.
Summary: Depends On D2113
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2114
Summary:
This patch adds support for the `Sequence<T>` type. This is largely a
straightforward type propagation patch, but there are a few notable things:
1. We allow `[iid_is(x)] Sequence<nsQIResult>`, so Sequence can be Dependent.
2. `Sequence<T>` is reflected into C++ as a `nsTArray<T>`, which is different
than WebIDL's `mozilla::dom::Sequence<T>` type. This decision was made for
general ergonomics reasons, as `nsTArray<T>` is more prevailent throughout
the codebase, and lengths in this case cannot be controlled by content, as
XPConnect is only exposed to Chrome JS.
3. Owned pointers in `Sequence<T>` are not reflected as their owned
counterparts. For example, `Sequence<nsISupports>` is reflected as
`nsTArray<nsISupports*>` rather than `nsTArray<RefPtr<nsISupports>>`. This
was done to avoid depending on `RefPtr<T>` and `T*` having the same
in-memory representation, however if that is considered an acceptable
dependency, it would be nice to support that.
4. We also don't reflect singly-owned pointers as their owned counterparts. For
example, `nsTArray<nsIIDPtr>` would be reflected as `nsTArray<nsIID*>`
rather than `nsTArray<mozilla::UniquePtr<nsIID>>`. If we are willing to
depend on `mozilla::UniquePtr<T>`'s in-memory representation, we could also
do this, however.
5. There are no restrictions on what types can appear inside of a `Sequence<T>`
or what can appear inside an `[array] T`. We may want to add restrictions
either at the xpidl level or in XPConnect.
Depends On D2109
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2110
Summary:
The background logic for handling lists of XPConnect values is similar between
`[array] T` and `Sequence<T>`. The major differences are with regard to how
native length is determined, how 'null' and 'undefined' are handled, and how
native buffer allocation is handled.
This patch modifies the JSArray2Native function to make it generic over an
allocation strategy function, which can be implemented for each of `[array] T`
and `Sequence<T>`. The function takes in a `uint32_t*` pointer, pointing at the
computed length of the JS array. The callback can then allocate the correct
backing buffer, and optionally modify the length to copy.
The NativeArray2JS function is also modified to make it directly take a pointer
to the native buffer rather than determining it from a pointer to an `[array] T`
parameter.
Depends On D2105
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2106
Summary:
A goal of the Sequence<T> work is to allow using more complex types within lists
in XPConnect. For example, we ideally want to support `Sequence<AString>`,
rather than requiring people to use the unergonomic 'wstring' type.
These types require initialization before they can be read into. Currently this
initialization for parameters is directly handled by XPCWrappedNative's
CallMethodHelper object.
This patch introduces a new function to the `xpc` namespace to initialize a
specific value from an uninitialized state to a safe state.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2105
Created a runtime hook to handle DOM nodes. Specialized ubi::Concrete for nsINode-inheriting objects. Displayed outgoing nsISupports* edges on reflector JSObjects. Generated outgoing child edges from nsINodes by examining their children. Updated the UbiNodeCensus to ignore zone checks if there is no zone to be found in a node.
We were previously failing to send blobs to new content processes, which was a
problem for those processes. But we were also attempting to extract blobs for
new entries that we were serializing after we'd extracted their structured
clone data, and their blob array had been thrown away (which was a problem for
all processes).
This patch fixes both problems.
MozReview-Commit-ID: 3qbAmUTA85g
--HG--
extra : rebase_source : 87ed9356aa23ae83762a887cf12ba1f466e7bf61
This removes AutoMaybeEnterFrameRealm. Most places pass cx->realm->principals: it preserves behavior when the (possibly wrapped) SavedFrame and cx are same-compartment. The main exception is the JSStackFrame DOM bindings code where we have to be a bit smarter about which principals to use.
The stack object might be a CCW and we want to make it impossible to get a CCW's global. Now the caller has to supply a same-compartment global object, so we no longer rely on getting the CCW's global.
My best guess as to the failures here is that we're not actually
reaching the busyWait call by the time the interrupt callback fires,
and thus we're killing unrelated scripts.
MozReview-Commit-ID: GvCJzBcJlXm
Differential Revision: https://phabricator.services.mozilla.com/D2162
--HG--
extra : moz-landing-system : lando
I initially tried to avoid this, but decided it was necessary given the number
of times I had to repeat the same pattern of casting a variable to void*, and
then casting it back in a part of code far distant from the original type.
This changes our preference callback registration functions to match the type
of the callback's closure argument to the actual type of the closure pointer
passed, and then casting it to the type of our generic callback function. This
ensures that the callback function always gets an argument of the type it's
actually expecting without adding any additional runtime memory or
QueryInterface overhead for tracking it.
MozReview-Commit-ID: 9tLKBe10ddP
--HG--
extra : rebase_source : 7524fa8dcd5585f5a31fdeb37d95714f1bb94922
Some callers of PLDHashTable::Search() use const_cast, some others are not
const methods due to non-const PLDHashTable::Search().
This patch removes const_cast from the former and mark some methods of the
latter const.
MozReview-Commit-ID: C8ayoi7mXc1
--HG--
extra : rebase_source : 2cba0339756e3278ba6e5f0e8a11e68217a61d34
This class allows one read-write copy of a map in the parent process to share
data with multiple read-only copies in child processes. The maps only hold
onto data as structured clone blobs, and deserialize them each time a key is
read.
This commit only provides the bare-bones data structures. Follow-ups will add
bindings, change events, and automatic flushes.
MozReview-Commit-ID: LimwfmFBNOi
--HG--
extra : rebase_source : e43985c39bd1cfd05a2ad536b0d7f74db494a753
extra : source : c27295337b4c16e2a178106a3aa873d2a0e5a1f4
When we use the preload cache for some non-cached local scripts in loadSubScript,
we will keep the global that the script was compiled for alive, resulting in a
leak.
We will compile these chrome:// and resource:// scripts with codebase principal in
the XPConnect compilation scope when using mozJSSubScriptLoader to load scripts
synchronously. When the script is evaluated, it will be cloned into the target
scope to be executed. By compiling the script in a different scope, we can avoid
keeping the global that the script was compiled for originally alive.
MozReview-Commit-ID: HYSTvmPCbyR
--HG--
extra : rebase_source : 1ee540e08b9eda9046539f6f20f596732a651034
We only run process scripts once per process, so there's no need to compile
them for the compilation scope, or to keep a separate cloned copy alive for
the length of the session.
This patch changes the caching behavior of message managers to compile
single-use scripts directly for the target global, and avoid caching them for
the rest of the session. It also changes the preloader to drop references to
these scripts after they've been executed and/or encoded, as appropriate.
MozReview-Commit-ID: EfKo2aYbBxl
--HG--
extra : rebase_source : aebc5812bef4413d497ac4fdb59aced00a5a4c8e
extra : absorb_source : cf5795eb0bff47d08b1ab45f002afb3f05109c93
extra : histedit_source : e92619d2a818095241c52d8f1961ccad38300d32
This class implements a shared memory key-value store that fits into a single
memory mapped segment. All of the runtime data for its instances are stored in
the shared memory region, which means that memory overhead for each instance
in each process is only a few bytes.
Importantly, the key and value strings returned by this class are also
pointers into the shared memory region, which means that once an instance is
created, its memory cannot be unmapped until process shutdown.
For the uses I intend to put it to, this is a reasonable constraint. If we
need to use it for shorter-lived maps in the future, we can add an option to
return non-literal dependent strings that will be copied if they need to be
kept alive long term.
MozReview-Commit-ID: 5BwAaDsb7HS
--HG--
extra : rebase_source : b472fe628018f88a2c4d6b3de4b7143aeca55e14
extra : absorb_source : 5cdeb568cfd2b4a5a767191402e699e61e653b3b
This class allows us to map a read-write shared memory region, and then safely
remap it read-only, so that it can be shared with sandboxed content processes.
MozReview-Commit-ID: 2PJMQgOwA4V
--HG--
extra : rebase_source : c556cabfa7d379a91dc9ef7171ac0a7d7d8fb32e
extra : absorb_source : e78e304ed95891c694050f79a0bb5d40d11ee884
This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
--HG--
rename : testing/specialpowers/bootstrap.js => testing/specialpowers/api.js
extra : rebase_source : 0faf7d21c8868c957ddc7fede0d56809f27dc161
extra : intermediate-source : ffb9ce93b92dd6396bfe038d3f6a8bcf929ec277
extra : source : cca596eadd0437dc75b75c119b6c7a405805f703
This is a quick-and-dirty port. It might be nice to replace
SpecialPowersObserver with the webextensions content script injection
system at some point, but that isn't practical right now (since WE experiments
cannot implement new APIs visible to content scripts).
MozReview-Commit-ID: GinCu3VcbWK
--HG--
rename : testing/specialpowers/bootstrap.js => testing/specialpowers/api.js
extra : rebase_source : 8be131e80d95a6bf6e86c994fdfa40c14ba610eb
extra : source : cca596eadd0437dc75b75c119b6c7a405805f703
Summary:
This patch adds the infrastructure to move Activity Stream (about:newtab, about:home,
and about:welcome) into its own special content process - the privileged content
process. This feature of running Activity Stream in the privileged content process
is disabled by default. (See "browser.tabs.remote.separatePrivilegedContentProcess"
preference.) We can deal with other about: pages in a follow-up.
Reviewers: mconley
Tags: #secure-revision
Bug #: 1469072
Differential Revision: https://phabricator.services.mozilla.com/D1731
MozReview-Commit-ID: 5gIrP4LxcIt
--HG--
extra : rebase_source : d43c411ae60aad3d5a3a496e6729de0b547b4acd
In file included from objdir/js/xpconnect/src/Unified_cpp_js_xpconnect_src1.cpp:110:
js/xpconnect/src/nsXPConnect.cpp:76:37: error: use of undeclared identifier
'profiler_register_thread'
JS::SetProfilingThreadCallbacks(profiler_register_thread, profiler_unregister_thread);
^
js/xpconnect/src/nsXPConnect.cpp:76:63: error: use of undeclared identifier
'profiler_unregister_thread'
JS::SetProfilingThreadCallbacks(profiler_register_thread, profiler_unregister_thread);
^
MozReview-Commit-ID: HrBGEkByEum
--HG--
extra : rebase_source : b588e8f04d44d07c348120efc6008e6c24b8949e
This does mean that if the node is adopted back into the original document the
expandos would end up on the reflector at that point. I think that's OK;
people shouldn't be adopting things in that direction. Futhermore, if they
adopt, then set expandos, then adopt back they already get this behaviorl
So if we decide we don't want that, we should probably just avoid copying own
props when reparenting into a global whose principals don't subsume the old
global.
Originally, the ScriptPreloader stopped recording and wrote its cache when the
browser-delayed-startup-finished notification fired for the first window, but there
are other scripts (both in the content and WebExtension processes) that might run
soon after that we also want to cache.
This patch still makes the parent process stop recording scripts after
browser-delayed-startup-finished, but only prepares and writes the cache
once browser-idle-startup-tasks-finished fires, when it is much more likely
that the content and WebExtension caches are ready to go.
MozReview-Commit-ID: KiBEVvuqQkA
--HG--
extra : rebase_source : 6f0fde65cdafdecf72242a06416fef10304637b8
This allows us to lazily import global properties using
Cu.importGlobalProperties. Aside from making it easier to avoid lazily
importing these properties, it also defines them all in the shared JSM global
so that we don't risk re-creating them in Sandboxes or frameloader globals.
MozReview-Commit-ID: GV6shguUlIG
--HG--
extra : rebase_source : 6b9269f3b33fe085c5ed63ee16e5b4ce9e5343a4
Inheriting PerThreadAtomCache on CycleCollectedJSContext permits use of
static_cast, avoiding one level of indirection compared to adding a
CycleCollectedJSContext* to PerThreadAtomCache.
PerThreadAtomCache is over 18kB, and so WorkerJSContext and WorkletJSContext
are moved from the stack to the heap.
MozReview-Commit-ID: 6jdJeZcviK4
--HG--
extra : rebase_source : 3c2accb71faf3f017a44c405ae0484e57aaf039c
* GetScriptCompartment => GetScriptRealm
* Adds IsSystemRealm in addition to IsSystemCompartment and uses it where we can.
* JS_GetCompartmentPrincipals and IsSystemCompartment now release-assert they have a single realm. This is temporary until we know what Gecko will do/need exactly.
At some point I'll audit the obj->realm() calls for CCWs; removing RealmBehaviorsRef(obj) prepares for that.
Also, RealmBehaviorsRef(realm) could be removed and we could use RealmBehaviorsRef(cx) everywhere, but it seems reasonable to keep it.
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Some of the less trivial changes:
* When we allocated a symbol, we used the atom realm's RNG to create a hash code [0]. Instead of this I added a RNG for this to the runtime.
* IsCompilingWasm returned true if the JitContext's realm is nullptr, but that's now also true when we initialize the trampolines stored in the atoms zone. To fix that I added a CompileZone* to JitContext, in addition to the CompileRuntime and CompileRealm, and we now check the zone instead of the realm in IsCompilingWasm.
* JSContext::hasEnteredRealm is only called in DEBUG builds so I made hasEnteredRealm and enterRealmDepth_ #ifdef DEBUG.
Tracing the script members held alive by PrecompiledScript objects can be
expensive, especially for large scripts. It would be nice if we could avoid
tracing them when possible.
Most of the time, when PrecompiledScripts are alive, they're held alive by
black roots, and have black JS wrappers. In those cases, there's no chance of
them creating garbage cycles, and we can just mark their script children
black.
MozReview-Commit-ID: KnkJfznJZBx
--HG--
extra : rebase_source : da0da30265c3f752c9aba177bf510937a743e49e
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 344c380ddaaf42a1fd820a26b762c61ee9e2d524
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 35362bc94068103367f46b23a14cb3831cd86990
The ScriptPreloader stopped recording before browser-delayed-startup-finished before, but there
are other scripts (both in the parent and content processes) that might run soon after that we
also want to cache. This increases the probability that those scripts are noted by the
ScriptPreloader cache.
MozReview-Commit-ID: KiBEVvuqQkA
--HG--
extra : rebase_source : 4c1bffa882b0641f93260867ac8a4334b1269e99
This implements a new kind of lazy getter in XPCOMUtils that creates an object (implemented as a JS Proxy) that is resilient to be passed around as references to other functions, and will only evaluate the getter when it really needs to be used
This one sucks. I found out when running tests that we exploit some edge
case behaviour in our tests where passing an invalid value to an xpidl
array parameter will be passed as an empty array...
I figured that just respecting this behaviour for now is the easiest
approach, but we will probably want to fix it in the future.
Current XPIDL native arrays currently also require a custom entry point. With
the new arraylen parameter we can handle them in JSData2Native/NativeData2JS. As
these methods are more complex and don't share logic with an existing codepath,
I keep them in external helper methods.
XPIDL supports explicitly sized string types. These types currently have to be
handled by a separate entry point into XPCConvert, and don't share any logic
with the implicitly sized string types.
If we just add an array length parameter to the basic JSData2Native and
NativeData2JS methods we can handle them in the same place as every other type.
This also allows us to share a lot of code with non-sized string types, which is
nice :-).
When a jsval passed from JS code it needs to be stored in a nsXPTCVariant
object. This object is not rooted by default, as it is stored in some
C++-allocated memory. Currently, we root the values by adding a custom root
using the `js::AddRawValueRoot` API, which is deprecated, and only used by this
code and ErrorResult.
This also has the unfortunate effect that we cannot support XPCOM arrays of
jsvals, as we cannot root all of the values in the array using this API.
Fortunately, the JS engine has a better rooting API which we can use here
instead. I make the call context a custom rooter, like the SequenceRooter type
from WebIDL, and make sure to note every jsval when tracing, both in arrays and
as direct values.
This should allow us to avoid some hashtable operations with roots when
performing XPConnect calls, and remove a consumer of this gross legacy API.
In addition it allows us to support arrays. This will be even more useful in the
future when I add support for sequence<T> (which is a nsTArray<T>) to xpidl and
xpconnect.
In XPConnect, native values are passed around within nsXPTCMiniVariant objects.
an [nsXPTCMiniVariant] contains 64-bits of data in a union type.
nsXPTCMiniVariant values are created by the platform-specific glue code and
passed into XPConnect proper when calling from C++ into JS.
When calling from JS into C++, we instead create nsXPTCVariant objects and pass
them into the glue code. These objects have extra information in addition to the
nsXPTCMiniVariant: namely they also have a `type` field with the type stored in
the variant, space for flags, and a `ptr` field which is passed over IPC instead
of the inner nsXPTCMiniVariant when a flag (`PTR_IS_DATA`) is set.
The JSValue type in XPConnect is always passed as a pointer to a JSValue object,
both for in parameters and out parameters. This is handled by making the JSValue
type be unconditionally flagged as [`IsIndirect()`] This flag is also used for
all types of outparameters.
When the `IsIndirect()` flag is set, it means that the actual data is stored in
the nsXPTCVariant's val field, and it sets the flag to tell the glue code to
instead pass the `ptr` field (which is always pointing to the `val` field for
[legacy reasons]) into the C++ code.
In contrast "dipper" is a different and super weird flag. Currently only the
string class types (nsACString & nsAString) are marked as "dipper". A "dipper"
type is always passed as an "in" type (and thus always passed "directly"), even
when it's actually an out parameter.
XPConnect treats these types as though they are pointer types (nsAString*). This
means that there is no space in the nsXPTCVariant to store the actual nsAString
types when passing from JS into C++, so these values have to be allocated by a
different mechanism (in the current code, there is a size 2 buffer for each
string type in the context and once that buffer is exceeded, we heap allocate
the nsString values).
In effect, the current state looks something like this:
+------------+---------------------+---------------------+
| type | out (xpt/native) | in (xpt/native) |
+------------+---------------------+---------------------+
| TD_INT32 | indirect (int32_t*) | direct (int32_t) |
+------------+---------------------+---------------------+
| TD_JSVAL | indirect (JSValue*) | indirect (JSValue*) |
+------------+---------------------+---------------------+
| TD_ASTRING | direct (nsAString*) | direct (nsAString*) |
+------------+---------------------+---------------------+
This patch ensures there is enough space in the nsXPTCVariant to fit the
nsString value, and switches string class types to being unconditionally
indirect instead of using the dipper system. This allows us to delete a ton of
dipper-specific code, and unify the indirect and string class codepaths.
This only affects the size of nsXPTCVariant objects, and does not affect
nsXPTCMiniVariant objects. nsXPTCVariant objects are never allocated by the
platform-specific binding code, rather, they are allocated in an AutoTArray on
the stack as part of the CallMethodHelper object.
The size increase is a total of 1 word, so 4 bytes in 32-bit builds, and 8 bytes
in 64-bit builds, which is ignorable for stack allocated objects.
[nsXPTCMiniVariant]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#20-47
[`IsIndirect()`]: https://searchfox.org/mozilla-central/rev/c0d81882c7941c4ff13a50603e37095cdab0d1ea/xpcom/reflect/xptinfo/xptinfo.h#371
[legacy reasons]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#66-79
It used to be that in XPConnect there were many different pieces of code for
each place where we may need to clean up some untyped values based on their
nsXPTType information. This was a mess, and meant that every time you needed to
add a new data type you'd have to find every one of these places and add support
for your new type to them.
In fact, this was bad enough that it appears that I missed some places when
adding my webidl support! Which means that in some edge cases we may clean up
one of these values incorrectly D:!
This patch adds a new unified method which performs the cleanup by looking at a
nsXPTType object. The idea is that this function takes a void* which is actually
a T* where T is a value of the nsXPTType parmaeter. It clears the value behind
the pointer to a valid state such that free-ing the memory would not cause any
leaks. e.g. it free(...)s owned pointers and sets the pointer to `nullptr`, and
truncates nsA[C]String values such that they reference the static empty string.
I also modify every one of these custom cleanup codepaths to instead call into
this unified cleanup method.
This also involved some simplification of helper methods in order to make the
implementation cleaner.
Bogdan Tara
Kristen Wright
Boris Zbarsky
Brian Hackett
Gabriele Svelto
Nika Layzell
Coroiu Cristina
Jan de Mooij
Nicholas Nethercote
Jon Coppeard
agashlin@mozilla.com
Gijs Kruitbosch
Cosmin Sabou
Andreea Pavel
Kris Maglione
Narcis Beleuzu
Brindusan Cristian
Csoregi Natalia
Nazım Can Altınova
Tiberius Oros
Bobby Holley
Margareta Eliza Balazs
Andrea Marchesini
Masayuki Nakano
Matthew Gaudet
Gurzau Raul
imjching
Ciure Andrei
Christian Holler
Olli Pettay
Andrew Swan
André Bargull
Jeff Gilbert
Andi-Bogdan Postelnicu
Tom Schuster
Jan Beich
Joel Maher
Mike Conley
Steve Fink
Peter Van der Beken
Karl Tomlinson
Miko Mynttinen
shindli
arthur.iakab
Emilio Cobos Álvarez
Markus Stange
Noemi Erli
Felipe Gomes