This patch doesn't change behavior; it just removes some redundant checks.
(Note that the tight-scoping around nsAutoMicroTask/ReduceAnimations is
important for the RAII object to be torn down at the intended time; but it
doesn't need its own if-check.)
Depends on D191909
Differential Revision: https://phabricator.services.mozilla.com/D191911
This patch doesn't change behavior.
This is a bit gross, but it helps us make better use of the backtrace to figure
out what's going on in a given crash report.
Differential Revision: https://phabricator.services.mozilla.com/D191909
This doesn't affect behavior; it's just a pure refactoring, moving code from
being inline to being in a helper function.
Differential Revision: https://phabricator.services.mozilla.com/D191908
These are small but they do show up in sp3 profiles.
IsPaintingToWindow is always true, so just assert it.
HaveScrollableDisplayPort is a simple pointer check, whereas AsyncPanZoomEnabled needs to jump several pointers (and WantAsyncScroll is slower yet), so change the order.
HasNonMinimalNonZeroDisplayPort is not needed unless we are inside that if, so don't call it outside the if.
Differential Revision: https://phabricator.services.mozilla.com/D191599
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This patch removes the old docshell timeline and timeline markers codebase and replaces them with equivalent Gecko profiler marker. This patch also fixes Bug 1834143, which is a subset of 1421651.
Differential Revision: https://phabricator.services.mozilla.com/D184217
This is just extending our existing progress-listener object that we use
functionally in the test, to implement a few more of the nsIWebProgressListener
callbacks so we can see if they're firing in some unforeseen way that can help
us identify why the test is intermittently timing out.
I'm just cribbing the full list of callbacks from
https://searchfox.org/mozilla-central/source/uriloader/base/nsIWebProgressListener.idl
without worrying too much about their applicability here.
Differential Revision: https://phabricator.services.mozilla.com/D191501
It looks like our formula doesn't work well for 0deg and 90deg because
it's not a triangle when theta is 0deg or 90deg. So we handle them
separately.
Differential Revision: https://phabricator.services.mozilla.com/D191495
This isn't content we're showing to any users; it's essentially a crashtest (written as a browser-chrome test), trying to set up a set of conditions that used to trigger a crash.
Thus, we are excluding this click event from accessibility checks and removing the `fail-if` annotation that was added before the investigation by the bug 1854520.
Differential Revision: https://phabricator.services.mozilla.com/D190362
These days, after bug 1853323, about:PreferenceStyleSheet is basically
just an empty sheet for most users. For the ones that isn't, it's either
slightly or completely broken (see below).
If we were to implement this today, we'd do it with privileged env()
variables or media queries, and add a bunch of tests for different
combinations, but I don't think it's worth the effort:
* There's no UI for any of these prefs.
* There are no tests for any of these prefs.
* browser.display.focus_ring_or_anything is not great, it's better
replaced by browser.display.show_focus_rings, which actually makes
the :focus-visible pseudo-class work. Otherwise the native controls
may show no rings even though this pref is set.
* for browser.display.focus_ring_style = 0, the color used
(-moz-mac-focusring) is not implemented in any non-macOS platform.
* The ::-moz-focus-inner rules are completely useless nowadays, because
::-moz-focus-inner only works on the windows native theme (which
isn't used on content).
* The focus colors are not color-scheme aware.
So given those, and that if you want the specific current behavior,
these are trivially implementable as a web extension (by using a user
stylesheet), I think we should just remove this code altogether.
Differential Revision: https://phabricator.services.mozilla.com/D190464
Based on testing we can simplify the current setup and also ensure that we don't trigger a RefreshDriver tick too soon
(so that we don't get two ticks when we expect only one).
This gets us even closer to Chrome's raf handling.
Differential Revision: https://phabricator.services.mozilla.com/D190361
Also, drop `nsLayoutUtils::ComputeGeometryBox()` and avoid doing mapping
in `ComputeHTMLReferenceRect()` and `ComputeSVGReferenceRect()`. The
caller should handle it properly because each property uses its own mapping
between CSS box and SVG box.
Note:
1. mask-clip-3.html is copied from mask-clip-1.html but just replace
css boxes with svg boxes.
2. mask-clip-4.html is copied from mask-clip-2.html but just replace
svg boxed with css boxes.
Differential Revision: https://phabricator.services.mozilla.com/D188316
It seems mask-origin/mask-clip/clip-path use different mapping for
geometry-box. We should specialize each one. In this patch, we focus on
clip-path.
Differential Revision: https://phabricator.services.mozilla.com/D188146
For initial about:blank, nsSubDocumentFrame::Init might not have an
extant browsing context yet. Some code did deal with that properly
(MaybeUpdateEmbeddedColorScheme for example), but some other didn't.
Consistently propagate data to our browsing context after ShowViewer to
fix this.
Differential Revision: https://phabricator.services.mozilla.com/D190275
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Note, I'm deleting the null-check from UpdateIntersectionObservations, since
I'm essentially hoisting it up one level (and I don't think there's anything
that could null out mPresContext in the intervening code).
Differential Revision: https://phabricator.services.mozilla.com/D190367
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to fail-if the failing tests altogether and then handle each one of them individually.
This task is to add `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific bug 1854521
- Explore capturing click events for a11y_checks: bug 1692110
Depends on D188919
Differential Revision: https://phabricator.services.mozilla.com/D188920
We are working on [enabling Tier 2 a11y-checks to ensure our products have basic accessibility built-in (bug 1692110)](https://bugzilla.mozilla.org/show_bug.cgi?id=1692110) and before that, we need to prepare the existing code base. While we triage and investigate existent tests that would fail once the a11y-checks are enabled in the CI, we are going to skip the failing tests altogether and then handle each one of them individually.
This task is to skip with `fail-if` condition of the failing tests while we continue investigation into the reasons these tests failed and to be able to backtrack these tests once they're resolved.
Related bugs:
- Disabling tests: meta bug 1848402
- Investigation and remediation for components with disabled tests: meta bugs 1848394 and 1854227, component-specific bug 1854521
- Explore capturing click events for a11y_checks: bug 1692110
Differential Revision: https://phabricator.services.mozilla.com/D188920
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
This is probably something we want to move towards, so it doesn't hurt
adding a pref to allow people to experiment with it.
Differential Revision: https://phabricator.services.mozilla.com/D189919
These days it's just a very thin wrapper over an nsTArray of
ResizeObservers. We also schedule notifications for resize observations
for the whole BrowsingContext tree at once, so there's no point on
individually keep track of them.
Differential Revision: https://phabricator.services.mozilla.com/D190113
