Use natively supported mix-blend modes, where appropriate. Disabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D26350
--HG--
extra : moz-landing-system : lando
This patch changes glyph requests in the resource cache to occur
as soon as a text run is found to be visible, rather than during
the prepare_prims pass.
This has two major benefits:
- (with other patches) will allow some batching code to run
during the prepare_prims pass.
- allows glyph raster worker threads to start earlier in the
frame, which may lead to less time blocking on the workers.
Differential Revision: https://phabricator.services.mozilla.com/D29458
--HG--
extra : moz-landing-system : lando
This is a first step towards allowing (some) batching work to be
done during prepare_prims pass rather than render pass building.
This is prep work related to output different batch lists for a given
picture (e.g. a different batch list per dirty region), rather than
replaying the same batch list.
Differential Revision: https://phabricator.services.mozilla.com/D29445
--HG--
extra : moz-landing-system : lando
This also adds an isTopFrame attribute to the FrameCrashedEvent binding, which
returns true if the frame that crashed was the top-most one.
Differential Revision: https://phabricator.services.mozilla.com/D29236
--HG--
extra : moz-landing-system : lando
This early return is just an optimization to prevent the DAG from becoming too complex, and if we're keeping the list linked, then we know it won't be getting more complex on the current paint.
Future paints that actually modify the list will still take this path.
Differential Revision: https://phabricator.services.mozilla.com/D29408
--HG--
extra : moz-landing-system : lando
The nsBrowserStatusFilter flushes pending status and progress updates when an
OnStateChange event for a STATE_STOP state is triggered. This may run its
OnProgressChange and OnStatusChange listeners, which may in turn run arbitrary
JavaScript or even remove the web progress listener from the filter. When this
happens, we will continue to call the OnStateChange event handler on a listener
that is now a nullptr, causing a crash.
We now explicitly check that we still have a web progress listener before
continuing and have renamed the ProcessTimeout function to a more descriptive
name (CallDelayedProgressListeners) that indicates what it actually does.
Differential Revision: https://phabricator.services.mozilla.com/D28123
--HG--
extra : moz-landing-system : lando
This test uncovered a couple of problems:
(1) UrlbarController.handleKeyNavigation relies on event.defaultPrevented to tell whether the one-offs handled the key event. That's a problem when combined with deferring the down arrow key.
handleKeyNavigation is called twice in that case. The first time, the event is deferred (so executeAction = false), and handleKeyNavigation calls event.preventDefault. The second time, the event is being replayed, but defaultPrevented is true from the previous call regardless of whether the one-offs actually handled the event.
So handleKeyNavigation always returns early because it thinks the one-offs always handled the event, so it never properly replays down arrow keys.
(2) UrlbarProviderUnifiedComplete's query promise is never resolved when the query is canceled. That's a problem in general of course but I tripped over it in this test because I need to check results after the query is canceled, and the test ended up hanging since UrlbarTestUtils waits for the query to finish in order to get its results.
It's not a problem in UnifiedComplete itself per se because of course awesomebar uses UnifiedComplete too, and it doesn't have this problem. The difference is that nsAutoCompleteController::StopSearch calls input->OnSearchComplete() (via PostSearchCleanup): https://searchfox.org/mozilla-central/rev/b756e6d00728dda4121f8278a744381d8643317a/toolkit/components/autocomplete/nsAutoCompleteController.cpp#1433
Quantumbar's UnifiedComplete provider is missing that behavior, so this patch adds it by resolving its query promise when the query is canceled.
Differential Revision: https://phabricator.services.mozilla.com/D29300
--HG--
extra : moz-landing-system : lando
Disabled for now of course. This should be pretty uncontroversial I'd think.
Differential Revision: https://phabricator.services.mozilla.com/D28060
--HG--
extra : moz-landing-system : lando
We always include the combinator for pseudo-elements now (not including it was
just an optimization) in order to not match when nested pseudo-elements are
involved.
We could add a more generic check in `matches_simple_selector` like:
```
if element.is_pseudo_element() {
match *selector {
Component::PseudoElement(..) |
Component::NonTSPseudoClass(..) => {},
_ => return false,
}
}
```
But even that wouldn't be enough to make selectors like `:hover::marker` not
match on the `::before::marker` pseudo-element, plus that code is really hot.
So for now do the check on the `next_element_for_combinator` function. It's a
bit hacky but it's the best I could came up with...
While at it, simplify some checks to use is_pseudo_element() instead of
implemented_pseudo_element() directly.
Only the Rust patch as-is would make markers for ::before and ::after on list
items not show up, so we also need to switch ::marker to use ProbeMarkerStyle()
rather than ProbePseudoElementStyle(), since the marker should exist even if it
matches no rules.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
I'm going to unconditionally generate the PseudoElement combinator, and this
causes issues since we'll put the raw `::pseudo` selectors in the host bucket,
which is obviously wrong.
Differential Revision: https://phabricator.services.mozilla.com/D27528
--HG--
extra : moz-landing-system : lando