That gets the right behavior even with flex-shrink: 1. An alternative
would be to also set flex-shrink: 0, but I don't see how this min-height
is useful so may as well remove code. Either way.
Depends on D172767
Differential Revision: https://phabricator.services.mozilla.com/D172768
`DNRStore`'s `#getManifestStaticRulesets` method is currently using `extension.readJSON` to load the JSON files
for the DNR static rulesets enabled, but internally `extension.readJSON` calls `String.prototype.replace` with
a regular expression to remove inline comments from the JSON files data retrieved and that have a noticebeable
impact due to the size that the DNR rulesets size may likely have (especially compared to the usual size of
manifest.json and locale files may have).
Given that Chrome doesn't support inline comments in DNR rulesets, we can consider replacing the call to
`extension.readJSON` with `fetch`, which wouldn't allow inline comments in the rulesets JSON files but
it would have a smaller impact due to not going through a call to `String.prototype.replace` and through
the js RegExp evaluations.
Alternatively we may consider keeping the call to `extension.readJSON` but tweak it to make sure we opt
out from the call to `String.prototype.replace` for this particular call (by also tweaking readJSON
method to allow that).
Differential Revision: https://phabricator.services.mozilla.com/D172604
Otherwise the compiler tries to instantiate the generic version based on
its current architecture flags, which may not be enough, resulting in
error along those lines:
'xsimd::batch<float, xsimd::neon> vgainr' has incomplete type
Differential Revision: https://phabricator.services.mozilla.com/D172864
This is enabling the PLE and PLC rules across a much larger swatch of the code
base. The PLR and PLW are additionally enabled at the warning level (introduces
~2500 new warnings).
To avoid extraneous changes in people's patches, rules at the warning level are
excluded from --fix.
Differential Revision: https://phabricator.services.mozilla.com/D172358
This results in some changes from our current `isort` configuration. I'm
unclear if it's because ruff isn't at 100% parity with isort, they choose
different defaults or if I missed some configuration.
Either way, the changes all look reasonable to me (see child commit), so I'm
inclined to just accept the new import format it imposes.
Differential Revision: https://phabricator.services.mozilla.com/D172348
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
