Calling `profiler_save_profile_to_file` from lldb errored with "call to 'profiler_save_profile_to_file' is ambiguous", even though they're in different namespaces.
Differential Revision: https://phabricator.services.mozilla.com/D148360
There's no need to lazily create a renderer here. We already avoided
this in content processes, but there's no need to do so in the parent
process either.
This shouldn't change behavior, but might help with bug 1772691, and
generally seems cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D148337
The TODO comment (removed here) was correct that we could/should be using
BehavesLikeInitialValueOnBlockAxis instead of explicit `auto` / `none` checks
(since any value that behaves like the initial value will have the same
semantics as far as this code is concerned, in terms of not generating a
meaningful transferred constraint).
The explicit `minBSize == 0 check **is still needed** (or at least, it's still
useful), since 0 is trivially uninteresting as a transferred lower-bound, so
it's valid to exclude it from the guarded logic (and 0 is not handled by the
BehavesLikeInitialValueOnBlockAxis() check). In this patch I broaden it to
check IsDefinitelyZero(), though (to include 0%).
Hopefully the new code-comment and lambda make these checks clearer.
Differential Revision: https://phabricator.services.mozilla.com/D148079
This is the only meaningful consumer of
ServoCSSParser::GetParsingEnvironment right now, but seems worth fixing
before other folks add more.
Differential Revision: https://phabricator.services.mozilla.com/D148145
First, move the cached table cleanup code out of LocalAccessible::UnbindFromParent and into Shutdown.
This makes no practical difference - it gets called either way when the document shuts down - but it's a bit clearer what's happening this way.
Second, add an assertion to CachedTableAccessible::GetFrom to ensure it is only ever given a table.
I don't think it would ever be given anything else, but this makes that clearer.
Differential Revision: https://phabricator.services.mozilla.com/D148089
We're seeing crashes in the wild where we're trying to allocate a very large number of array elements.
This suggests that the column index is underflowing.
The only way I can think of that this could happen is if colspan is 0 on the first cell, in which case we'd do 0 + 0 - 1 and underflow.
That shouldn't be possible - layout shouldn't ever give us a row/colspanof 0 - but perhaps it's happening anyway.
If this happens, we'll now gracefully treat it as a span of 1.
I also added an assertion in case this helps us to track this down properly in future.
Differential Revision: https://phabricator.services.mozilla.com/D148087
When a DocAccessibleParent is destroyed, we don't call Shutdown on its RemoteAccessibles to avoid pointless cleanup overhead.
Previously, this meant we weren't cleaning up associated CachedTableAccessibles.
We now explicitly clean these up in DocAccessibleParent::Destroy.
Differential Revision: https://phabricator.services.mozilla.com/D148086
We already handled this for visible aria-labelledby/describedby subtrees based on a11y events.
However, when a subtree is hidden (whether via CSS or aria-hidden), it is completely removed from the a11y tree, so we can't use a11y events.
Instead, when a node is added to the DOM, we walk its ancestors looking for an aria-labelledby/describedby target.
We stop if the node or an ancestor has an Accessible, since that means it will be handled elsewhere.
This also limits the number of ancestors we walk for each inserted node, thus decreasing the performance impact of this change.
This doesn't catch all possible mutations in a hidden subtree (e.g. removals or direct text node changes), but this at least fixes a case in Gmail.
Given performance risks, I think it makes sense to address specific cases as they arise.
Differential Revision: https://phabricator.services.mozilla.com/D147559
Before this patch, the content signature verifier
(nsIContentSignatureVerifier/ContentSignatureVerifier) would identify the root
it trusted based on the value of a preference. This patch changes the
implementation to require a specified hard-coded root to trust as with add-on
signature verification.
Depends on D146644
Differential Revision: https://phabricator.services.mozilla.com/D146645
Before this patch, the app signature verification code lived in security/apps/.
The majority of the rest of PSM is in security/manager/ssl/ and there's little
reason to have that extra directory for the app signature verification
implementation alone.
Differential Revision: https://phabricator.services.mozilla.com/D146644
Tooru Fujisawa
Mark Hammond
Gerald Squelart
Emilio Cobos Álvarez
Molnar Sandor
Daniel Holbert
Kagami Sascha Rosylight
Jim Blandy
Mozilla Releng Treescript
Updatebot
serge-sans-paille
Agi Sferro
criss
Niklas Baumgardner
Tim Nguyen
Dão Gottwald
Andreea Pavel
Butkovits Atila
Marian-Vasile Laza
James Teh
Dana Keeler
Jonathan Kew
Matthew Gaudet