This reuses the same codepath that we use for video controls, so that
the browser chrome can load external styles without FOUC.
Loading external styles as compared to internal styles is preferable,
because they can be shared across documents easily.
In the future, I think the idea is that the front-end would use CSS
modules, but meanwhile this should allow them to get along without
adding hacks to their code.
Differential Revision: https://phabricator.services.mozilla.com/D164245
APZ cannot currently scroll in directions which are overflow:hidden
(it does not know the full scroll range bounds in those directions).
Therefore, main-thread scrolling in these directions should not be
handed off to APZ.
Differential Revision: https://phabricator.services.mozilla.com/D161351
We are currently winding up with crashes that seem to be caused by ranges in a
selection having start and end containers in disconnected trees. Most likely
this has something to do with the ranges crossing shadow or native anonymous
boundaries, but it isn't clear.
This patch changes `DoSetRange` so we should hopefully assert as soon as we
get into that situation, rather than when we try to inspect the range. The
most obvious way to do this check would be to upgrade
`AssertIfMismatchRootAndRangeBoundaries` from a debug assertion to a
diagnostic assertion. Unfortunately, those checks are rather expensive, and
this code should be fairly hot.
Fortunately, the existing `!mIsPositioned` assertion should have the same
effect in all of the situations I've been able to think of. I've re-checked
the code a few times since I wrote the patch, and I believe it is sound. We
should hopefully find out within a couple of weeks if we need to do more.
Differential Revision: https://phabricator.services.mozilla.com/D162242
This patch series replaces the existing expand_categories method with a new one that makes us of the decision matrices to build the categories to display. The category matrix contains all combinations of variants, suites, platforms, and apps, for this particular category and each element represents whether some combination (variant, suite, platform, app) can run in this category. True means it can run, False means it can't.
At the end of the category expansions phase, we go through the categories to display and apply the restriction/negation queries to them. Doing this at the end allows us to be more precise in where we apply these. Note that the tests category, and variants were updated because this was a major change. Given the new restrictions on the categories, the number of categories are dramatically reduced. This is because we strengthened the criteria for being selected from only one variant being available, to all variants being available to run.
This new method with matrices uses more code, and memory versus the previous method, but it's much more maintainable and has new features to prevent the modification of the core code of the selector. In the previous solution, we needed to modify the core code when we added new restrictions. Now, this is all defined outside of the PerfParser. It's also much easier to tell where things are happening. Before, the code was very concentrated and a small change often caused unwanted/unexpected changes.
Differential Revision: https://phabricator.services.mozilla.com/D163839
This patch adds a method that builds decision matrices (see previous patch for info on this) for the category, and all variant combinations. At this stage, user requests (platforms, apps, and variants) get applied along with category restrictions. Furthermore, the restricted apps, and platforms are handled here. The next patch in this series shows how the categories are setup for this.
The category matrix has the form: {
category-name: {
variant_combination_1: variants_decision_matrix_1,
variant_combination_2: variants_decision_matrix_2,
...
}
}
Note how the category name is the base category name and hasn't been combined into a formal name for the selector to display. This is expected as the name creation happens within the expand_categories method.
Differential Revision: https://phabricator.services.mozilla.com/D163838
This patch adds the base method that is used to build our decision matrix for use in building up our categories. The decision matrix has the form: [
[
[
# Android platform, with apps as columns (firefox, chrome, chromium, fenix, geckoview, chrome-m)
[False, False, False, True, True, True]
# Android-a51
[False, ...]
[...]
[...]
[...]
[...]
] # Raptor
[
...
] # Talos
[] # AWSY
], # Base variant (uncombined, e.g. only live-sites or profiling)
[], # Another variant
]
Each element in this matrix tells us whether this particular (variant, suite, platform, app) combination is valid and runnable. If the element is False then the combination is not runnable. We make use of this to build up our categories and variant combinations. In the next patch, the variant-combination decision matrices are made by performing an AND operation on all of the corresponding elements in the individual variant decision matrices.
Some custom enumeration clases are also created for our various settings. The ClassificationEnum class provides the ability to use the Enum objects as indices to an array while also providing us with storage for a string identifier of the setting. This makes the category expansion code much more readable since we don't need to worry about where indices are, and the variabl naming is more succint.
Differential Revision: https://phabricator.services.mozilla.com/D163837
There was a bug found regarding how the Pageload (live) category was empty because the negation of live sites !live was inadvertently included. This is expected given the code we have. Instead of changing the behaviour of mach try perf when it comes to handling negation removals in the variants, we'll remove the live-site pageload category and add a restriction to the category definitions. At the same time, the Bytecode-Cached category is removed since it's a variant of some existing tests as well. Note that these removals are done in a later patch with a few other changes.
The tests are also modified to add new tests for this restriction, and change up the tests to ensure they aren't using bad categories.
Differential Revision: https://phabricator.services.mozilla.com/D163836
It looks like shapes are not being traced through MIR ops, instead relying on
the fact that shapes must always be tenured, and thus can only go away during
a compacting GC which will throw away Ion code anyway. Accordingly our
assumptions for why this optimization was okay were skewed.
Differential Revision: https://phabricator.services.mozilla.com/D164261
This was causing layout/generic/crashtests/1683126.html to timeout with named
pages enabled.
It is possible for a frame's PageValues struct to have both the start and end
values be set to null as further children are added. In that case, we can
avoid doing an extra allocation for each of that frame's continuations, as a
small optimization.
Differential Revision: https://phabricator.services.mozilla.com/D164266
As of bug 1791454 m-c and autoland both also imply the toolchains
branch, which doesn't work for every kind of task, some of which are
really meant to only run on those branches.
Differential Revision: https://phabricator.services.mozilla.com/D164149
The main reason to do this is to avoid polluting developer's terminals
_after_ Firefox exits; regular users shouldn't see `pingsender`
logging at all.
It's not technically difficult to actually launch with null stdout and
stderr, but it is quite onerous: we have at least two ways to launch
processes (`LaunchApp` and `nsIProcess`), with platform specific
differences and implementation specific options. This approach is at
least brief and easy to understand.
Differential Revision: https://phabricator.services.mozilla.com/D163153
