Also use mozilla::HashNumber where appropriate.
MozReview-Commit-ID: BTq0XDS5UfQ
--HG--
extra : rebase_source : 28f45a9b27e831e99620a2b575f373003f1301f2
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
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:
This patch allows parsing generic types, such as Sequence<T>, in XPIDL. It does
this by introducing a new type, TypeId, which contains both the name string and
an optional list of generic parameters.
Various places which use the xpidl.py library had to be updated to construct one
of these TypeId objects, as TypeId and `str` are not compatible types.
Depends On D2106
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2109
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
A couple of changes to ensure that the mochitest harness doesn't try to
start executing changes before the mochitest extension is loaded:
1. Fix the marionette driver to wait for an installed extension to
be started before returning from Addon:install
2. Wait for extension API onStartup() handlers to finish before
considering a webextension started.
MozReview-Commit-ID: 8YEdNn6s5qh
--HG--
extra : rebase_source : 67e9abadcda82d55ac73c33367ec65cdbf7b823d
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
We may not really receive a dragend event if we're fast enough.
Calling _onDragEnd multiple times is fine (it should be idempotent).
This particular exception was added in bug 978084 along with all the _onDragEnd
calls, but I don't think it's sound over-all.
I don't really want to dig into the XUL button code to see why drag end was
consistently firing there, unless you think it's really really needed :)
Differential Revision: https://phabricator.services.mozilla.com/D2019
--HG--
extra : moz-landing-system : lando
This was causing an empty message to appear in the
browser console when clicking the clear button.
This specific call was introduced 5 years ago without
much explanation, and since the error console is now
gone, I think it's safe to remove the call.
A test is added to make sure we do not print any extra
messages when clearing the browser console.
Differential Revision: https://phabricator.services.mozilla.com/D2551
--HG--
extra : moz-landing-system : lando
Looks like these used this mechanism for no great reason, and actually doing
this exposes trivially whether fingerprinting-resistance is enabled, which looks
like an anti-goal (if a media query parses correctly, and doesn't match either 1
or 0, then fingerprinting-resistance is enabled).
Differential Revision: https://phabricator.services.mozilla.com/D2493
MozReview-Commit-ID: 76tIIkwlpeP
Always assume allowed-for-all-content. There are a couple callers which weren't
doing that:
* A unit test -> removed.
* ComputeAnimationDistance: Used for testing (in transitions_per_property), and
for the animation inspector. The animation inspector shouldn't show
non-enabled properties. The transitions_per_property test already relies on
getComputedStyle stuff which only uses eForAllContent.
* GetCSSImageURLs: I added this API for the context menu page and such. It
doesn't rely on non-enabled-everywhere properties, it was only using
eInChrome because it was a ChromeOnly API, but it doesn't really need this.
Differential Revision: https://phabricator.services.mozilla.com/D2514
MozReview-Commit-ID: 4VOi5Su3Bos
The loop was mutating the nsCSSPropertyID used to guard the exit, which is
obviously wrong.
This branch is pretty rarely taken, since people don't usually specify `all` as
a transition property other than the first, for which case we take the fast path
with `checkProperties = false`. Our test-suite failed to catch this.
Added a crashtest that hangs without this patch.
The reason bug 1478990 regressed this is because it changed the order of
nsCSSPropertyID so that `p` actually went backwards causing the infinite loop,
but the bug was introduced (by me, whoops) in bug 1309752.
Differential Revision: https://phabricator.services.mozilla.com/D2552
MozReview-Commit-ID: Ii3D1FaZ31R
