Ruff is a very fast linter implemented in Rust and it can act as a drop-in
replacement for flake8. When running the same set of rules across all files
in mozilla-central (without mozlint), flake8 takes 900 seconds whereas ruff
takes 0.9 seconds.
Ruff also implements rules from other popular Python linters such as pylint,
isort and pyupgrade. There are even plans to implement feature parity with
black in the future. Ultimately, it can become our one stop shop for all Python
linting and formatting.
This stack will swap out all our Python lint tools for ruff (excluding black
for now).
Differential Revision: https://phabricator.services.mozilla.com/D172313
- Create wheel transactions for wheel events handled by APZ.
- Group wheel events with the current wheel transaction, so that all
wheel events in a wheel transaction are fired to the same element.
- Store the current event target for the first event in a wheel
transaction to be used for subsequent events.
- Add the dom.event.wheel-event-groups.enabled preference as a feature
flag for this behavior.
Differential Revision: https://phabricator.services.mozilla.com/D163484
Since visibility: collapse can still end up with a non-zero size for
e.g., padding and so. display: none is a better fit for this.
I noticed this while investigating the overflow mentioned in the
previous patch.
Differential Revision: https://phabricator.services.mozilla.com/D172935
There are two bugs here:
* We're sizing the popup in a way such as there's a <1px scroll range,
even though there's space to position the popup in the screen without
it. That's a layout bug I'll look into.
* When you hit that situation, we never detect that we're scrolled to
the end (because we have overflow and we're scrolled to the start
even when scrolled to the end as well).
This patch fixes the second. As per above it's not a complete fix, but
it needs fixing as well, hypothetically you could've hit this with
enough bookmarks to just hit the screen, plus 1 pixel.
I'll look into the first bug too.
Differential Revision: https://phabricator.services.mozilla.com/D172933
Since webrender was enabled by default this was causing pushes with
webrender-only changes to wrongly optimize out most tests.
Differential Revision: https://phabricator.services.mozilla.com/D172778
We are currently showing stacks for Error-like objects but not for DOMExceptions.
console.log("foo", new Error("bar")) would print bar's stacktraces, while we wouldn't for: console.log("foo", new DOMException("bar")).
Should we merge DOMException and Error previewers?
DOMException is only having code and result attributes which Error objects don't have.
Differential Revision: https://phabricator.services.mozilla.com/D172707
In MathML Core, the mathvariant attribute is now restricted to the mi
element and to value "normal". Some related WPT tests were updated in
[1]. This commit moves other tests assuming full mathvariant support
into our internal tests. It also tweaks some existing tests to only
rely on MathML Core features.
* mathvariant-basic-transforms-with-default-font.html: This test assumes support for italic, bold and bold-italic mathvariants so move it to internal tests.
* mathvariant-case-sensitivity.html: This one tests all mathvariant values, so move it to internal tests.
* mathvariant-double-struck-font-style-font-weight.html: This test assumes support for double-struck mathvariant so move it to internal tests.
* Other generated mathvariant-*.html tests for each value (other than "normal") are also moved to internal tests.
* direction.html: Remove use of mathvariant="bold" since this test is actually testing the dir attribute.
* presentational-hints-001.html: Verify that local author style for text-transform wins over presentation hints for mathvariant. Tweak it to use value "normal" on the mi element and text-transform: uppercase.
* presentational-hints-002.html: This is testing dynamic setting of mathvariant. Tweak it to use value "normal" on the mi element.
[1] https://github.com/web-platform-tests/wpt/pull/38490
Differential Revision: https://phabricator.services.mozilla.com/D172871
libtheora's assembler isn't compatible with clang's internal assembler even
if it convert to GNU AS syntax.
Since unified syntax is compatible with clang, I have to modify assembler files
for compatibility.
Depends on D172650
Differential Revision: https://phabricator.services.mozilla.com/D172651
Previously, we would do a fine-grained visibility check for
prims against the dirty rect stack (after coarse grained
tile visibility), then prepare the primitive, then determine
which command buffer(s) the prim should be added to, based
on which tile(s) the prim affects.
The patch changes this so that the fine-grained visibility
check returns a list of command buffer(s) that the prim
should be added to. This is passed to the prim prepare
step, and then used to directly add prims to the buffers
rather than checking which tiles are affected by the prim.
The motivation for doing this will become apparent in
follow up patches. We want to be able to encode
multiple command buffer commands per-prim, whereas it
was previously only possible to encode primitive
commands. By allowing prim-prepare to write directly
to the command buffers, rather than return a list of
primitive commands, we can write whatever commands
are needed. Future patches will use this to write
segment rect streams, and other information.
A side effect of this is that the `tile_rect` field
in the `PrimitiveVisibility` struct is no longer
required. This reduces the size of `PrimitiveInstance`
from 104 bytes to 88 bytes, which is likely to be
a reasonable performance win on pages that have
high primitive counts.
Differential Revision: https://phabricator.services.mozilla.com/D172081
The head files import NetUtil already, additionally, most of these don't actually do anything because they are not assigned
Differential Revision: https://phabricator.services.mozilla.com/D172943
el -> 0894acdd52c4c3fe9cefb85450974b0bfd82fbd0
lo -> 1e08bf1751b34d76194c659cf193820950ab45a2
my -> 83ed2c486c56c9631490d9caa4018294277513fb
sk -> b0925be36ca5039a12d29eb9e85d1a41b4625718
skr -> 1381a18c12a3e9eda83bffa74ae678afda877afc
sr -> ca40f6c6abb7093e41d642e24e77a39c94245e85
zh-CN -> 4a41931c7ed4928b0350a81d84d781d7cec9b7c0
In the patches for bug 1823215, we eliminated the use of a local copy of the glyph runs array
during SortGlyphRuns; but we call RemoveElementAt individually for each run to be coalesced,
which means potentially moving all the rest of the array multiple times. Instrumentation shows
that we sometimes end up with dozens of glyphruns to be coalesced (or even hundreds/thousands,
in pathological cases), which becomes quite inefficient.
Using RemoveElementsBy(predicate) instead will minimize the copying/moving of the remaining
array elements.
Differential Revision: https://phabricator.services.mozilla.com/D172945
Rulesets are atomic units. It does not select an arbitrary subset as an
"error recovery mechanism". This commits switches to the common quota
verification logic from the previous commit (RuleQuotaCounter).
Differential Revision: https://phabricator.services.mozilla.com/D172251
As a preparation for quota enforcement for session rules and dynamic
rules, this refactors the quota enforcement, by introducing a single
helper (RuleQuotaCounter) that keeps track of the rule counts and
is responsible for enforcing quotas.
This patch is purely a refactor, and the only behavioral changes are the
strings in error messages.
The error messages of static rules were previously not covered by unit
tests; this patch also improves test coverage in that area.
Lastly, removed TODO from the static rule loading. When a static ruleset
were to exceed the quota, the desired behavior is to ignore it and try
the next ruleset (this is consistent with Chromium).
Differential Revision: https://phabricator.services.mozilla.com/D172250
The math for directly calculating the endpoint of the arc is actually trivial,
and ArcToBezier is pretty expensive so should be avoided.
Differential Revision: https://phabricator.services.mozilla.com/D172929
