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
The standard WPT viewport is 800px wide, which (as a multiple of 100) can
conveniently resolve whole-number percentages without creating a fractional
size. But the default body-margins reduce it by 16px, to 784, which is less of
a round-number percent basis.
This was producing some fractional-pixel sizes in this test, which were causing
a fuzzy failure, due to antialiasing differences between how "width" and
"clip-path" handle fractional pixel sizes.
So, this patch just removes those margins, to give us 800px as our percent
basis, which avoids fractional-pixel sizes in this test.
Similarly: this patch also makes us use the Ahem font so that the test's "ex"
units will resolve to a predictable value, instead of whatever
potentially-fractional-value the default font would yield.
Differential Revision: https://phabricator.services.mozilla.com/D172917
See https://bugzilla.mozilla.org/show_bug.cgi?id=1821793#c2 for more info on
these failures.
In most cases here, I'm taking the fuzzy annotations from the exact values that
wpt.fyi reports for Firefox/Gecko. The only exception is for
clip-path-borderBox-1a.html, where I use a (higher) threshold taken from the
values that wpt.fyi reports for Safari/WebKit (which has a similar fuzzy
failure).
Differential Revision: https://phabricator.services.mozilla.com/D172916
Two issues:
* The part="content" of this popup is the <slot> itself. As such, it
now respects box-sizing, which our existing rules didn't account for.
* The <slot> didn't automatically fill the popup as old XUL did.
Explicitly set width/height.
Differential Revision: https://phabricator.services.mozilla.com/D172888
This patch makes the SearchInput a connected component, This allows us cleanup
all the seperate actions and reducer logic and makes it easier to add new SearchInput
with modifers functionality.
Differential Revision: https://phabricator.services.mozilla.com/D171034
The a11y module wants to traverse frames in native anonymous subtrees.
Therefore, this patch adds new option for allowing it, makes
`nsIFrame::GetFrameFromDirection` check it before comparing native anonymous
subtree root nodes, and makes `HyperTextAccessible::FindOffset` use the
option.
Differential Revision: https://phabricator.services.mozilla.com/D172759
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
It's called by `PeekOffsetFor*` and `GetPrevNextBidiLevels`, so it's used for
considering whether to put caret or move a selection range boundary.
Therefore, it should treat nodes which can be managed by `Selection` as
selectable. In theory, even if a native anonymous subtree does not have
an independent selection, its content nodes should not be the container of
the selection range boundaries of selection outside the subtree since
Selection API shouldn't expose nodes in native anonymous subtrees. Therefore,
it can simply treat content nodes in different anonymous subtrees are not
selectable.
Note that it's not standardized that how `Selection.modify` works with various
content nodes.
https://w3c.github.io/selection-api/#dom-selection-modify
And also Chrome cannot cross generated content like form controls with this API.
This could cause web-compat issues, but it does not make sense for caret
navigation, and anyway out of scope of this bug. Therefore, this patch just
adds the crash test.
Differential Revision: https://phabricator.services.mozilla.com/D172204
While Firefox builds for Android ARMv7 don't support non-NEON
processors, downstreams (including non-Android ones) may still want to
support them.
On the Firefox builds that don't support non-NEON processors, the NEON
flags are actually already passed globally, and they don't need to be
explicitly added. NEON_FLAGS is actually only meant to be used for
sources that specifically need NEON support even when the target doesn't
support it, for, e.g. specialized code behind runtime CPU detection.
So removing NEON_FLAGS is a no-op in practice when NEON processors are
already targeted.
Differential Revision: https://phabricator.services.mozilla.com/D172801
bg -> 01360f4bce126fd0758abb5759e8d88c809acd25
da -> b4c0357e5185526ae35a036310908bae02e97add
fr -> d95fa0593e2d0f5be54d2e5ab375ba85b39d4ba1
gn -> 6afafc4c9de1141ae87e63fe89e307e877f5b2c9
he -> 103f251af0aaee41278d9cc08085b431328562fa
hu -> d50652202be850d4e8df9d894828132059553835
ia -> ccf08deaa498f3e2491d7755f09651d3dae63bf5
is -> db0d33fcbe9a063a30ac28da1cd77f88a2218ec4
zh-CN -> 9ba36aef7f4fedbacc712c24ad4064b9565b6825
Highlights for this patch
- Support for the script overrides feature
- Overrides for html files are not supported
- Add styling to indicate overrides
- Add mochitests
Depends on D163600
Differential Revision: https://phabricator.services.mozilla.com/D163610
If the `.textContent` or `.defaultValue` attributes are used to change the content of a textarea,
according to the DOM Spec dictates first all children are removed and then a new child is added.
Removing all child elements must collapse the selection to 0.
However, the spec is not very precise on that matter,
see https://github.com/whatwg/html/issues/9028 .
This was currently not done (the selection was adjusted to the new length instead),
because the `Reset()` call was executed as a script runner,
therefore running (twice) after the new content has already been added.
With this change, the selection is adjusted to the new length explicitly
as soon as `ContentChanged()` is invoked, therefore updating it to 0
when content is removed.
Differential Revision: https://phabricator.services.mozilla.com/D172791