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
