The "catch-up" ticks are a strategy to make our repaint cycle more repsonsive
to user interaction, e.g. getting typed characters onto the screen sooner.
During pageload, this strategy isn't as crucial and may in fact harm the
overall pageload performance. So, this patch makes us hold off on these ticks
until after the page has finished loading.
Differential Revision: https://phabricator.services.mozilla.com/D126850
Depends on D126371
Now that the MarionetteEvents actors remain registered, MarionetteEventsChild.jsm and its Log.jsm dependencies both show up in the test browser_startup_content.js
Differential Revision: https://phabricator.services.mozilla.com/D126519
This patch no longer unregisters the MarionetteEvents actors. Instead when the session ends, a flag is set on sharedData so that MarionetteEventsChild actors stop sending events to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D126371
* `pystache` is unused.
* `funcsigs` is only needed for WPT - use the WPT version instead.
* `moz.build` has a bunch of obsolete/redundant references, clean
them up.
* `mohawk` isn't used directly, but is rather depended-on via
`taskcluster`. So, remove it from `requirements.in`.
Differential Revision: https://phabricator.services.mozilla.com/D126732
The `virtualenv` package version defines what `pip`/`setuptools`/`wheel`
that is installed in our venvs. Since we depend on the behaviour of
these tools, we should consider our venvs out-of-date if they weren't
created with the current `virtualenv` version.
Differential Revision: https://phabricator.services.mozilla.com/D126818
The previous behaviour was to:
* Never add a `pthfile` to the Mach virtualenv, and
* Always add Mach's paths to the `sys.path` when Mach initializes
However, this meant that `pip` would needlessly install packages
that already exist in the vendored environment.
Tweak `pth` behaviour so that `pip` behaves more efficiently.
Differential Revision: https://phabricator.services.mozilla.com/D120402
Before Win32k Lockdown, Canvas would ensure that it would get the fastest possible implementation by initializing
devices in content process before allocating persistent buffers for its backing.
However, with Win32k Lockdown it's no longer possible, as initializing Direct3D and Direct2D make Win32k calls that
crash the locked-down content process.
This issue is generally solved by Remote Canvas; however, Remote Canvas is disabled if the GPU process is disabled.
If that happens, the current behavior is to attempt to initialize hardware acceleration again, causing a crash when
Win32k Lockdown is in effect.
This patch changes the behavior so that the devices will not initialize if they are in a locked-down content process,
even if Remote Canvas is disabled. The effect is that Canvas will fall back to using Skia for everything.
Differential Revision: https://phabricator.services.mozilla.com/D126761
The code was written to hide the geometry highlighter when:
- the nodepicker was selected
- another node was selected in the markup view
- a node was hovered in the markup view
but this wasn't working as intended, as the line setting
the first of the event listeners was throwing, and we
don't have tests for this.
This patch fixes the faulty line and adds a test to check
that the geometry highlighter does hide on those actions.
We take this opportunity to use an AbortController to handle
the removal of the event listeners added when starting the
geometry highlighter.
Differential Revision: https://phabricator.services.mozilla.com/D126885
The default handler and character-data handler callbacks are identical
and some Windows compilers just reconciled them into a single function.
This, unfortunately, resulted in a RLBox runtime error: the same
callback was registered twice. This patch removes the duplicate handler
implementation and just sets the character-data handler callback as the
default handler.
Depends on D104658
Differential Revision: https://phabricator.services.mozilla.com/D126369
Using requestedIndex on the child side is hard, because there are race conditions when a session history load is triggered
and at the same time a non-session history load commits a new active entry.
Differential Revision: https://phabricator.services.mozilla.com/D126619
There's an existing algorithm to check if a virtualenv's installed
packages are up-to-date with its requirements. This patch
extracts that logic so that, in cases where we can't automatically
download needed pip packages, we can at least assert that the ones
installed to the system Python are sufficient to meet our requirements.
The current only case in which this system-checking logic is applied
is when starting the Mach virtualenv and the `MOZ_AUTOMATION` or
`MACH_USE_SYSTEM_PYTHON` environment variable is set.
Differential Revision: https://phabricator.services.mozilla.com/D122890
Eventually we should support all of them, but for now they are only used
by native code (unless you enable the color-scheme pref) and these will
be enough.
Differential Revision: https://phabricator.services.mozilla.com/D126737
The issue here is that we don't clear the cached intrinsic size of the
flex item, but this reproduces without flex at all.
The main issue is that we choose whether to clear the intrinsic sizes
from a reflow root (the outer svg in this case) based on whether the
reflow changes size or position:
https://searchfox.org/mozilla-central/rev/3fa5cc437a4937c621ea068ba5dc246f75831633/layout/base/RestyleManager.cpp#1224-1229
This is ~fine, except the nsChangeHint_ReflowChangesSizeOfPosition hint
can be "inherited" (and thus be cleared if already subsumed by a
parent):
https://searchfox.org/mozilla-central/rev/3fa5cc437a4937c621ea068ba5dc246f75831633/layout/base/nsChangeHint.h#465-469
This is ~fine, as we'll already start the reflow further up the tree (so
we don't need to start go past the reflow root), but we still need to
clear the ancestor intrinsics. We still get to StyleChangeReflow with
the ClearAncestorIntrinsics hint. We could pass that information down,
but the information is really already in via the IntrinsicChange.
I think it's just not correct to stop clearing intrinsic sizes if the
target is a reflow root and we get a TreeChange/StyleChange, regardless
of whether it changes size/position. It should also be a few less
instructions, though not that it matters.
Depends on D126812
Differential Revision: https://phabricator.services.mozilla.com/D126813