In nsBidiPresUtils::ResolveParagraph, we replace any block or segment separators
with space characters before bidi resolution. The use of nsString::ReplaceChar
here can appear in profiles, so it seems worth having a custom accelerated version
to handle the fixed set of separator codes. My local testing indicates this runs
between 5 and 10 times faster than the general-purpose function that has to
iterate over the provided set of characters at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D203125
We don't need to explicitly drop bidi-control frames from the original list in BidiLineData,
and make the corresponding updates to the Levels and IndexMap arrays; instead, we can just
skip over them when building the VisualFrames array.
Also, in nsBidiPresUtils::ReorderFrames we don't need a BidiLineData at all if there's only
a single frame on the line; we can just call RepositionFrame directly.
Differential Revision: https://phabricator.services.mozilla.com/D203124
In nsBidiPresUtils::ResolveParagraph, we replace any block or segment separators
with space characters before bidi resolution. The use of nsString::ReplaceChar
here can appear in profiles, so it seems worth having a custom accelerated version
to handle the fixed set of separator codes. My local testing indicates this runs
between 5 and 10 times faster than the general-purpose function that has to
iterate over the provided set of characters at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D203125
We don't need to explicitly drop bidi-control frames from the original list in BidiLineData,
and make the corresponding updates to the Levels and IndexMap arrays; instead, we can just
skip over them when building the VisualFrames array.
Also, in nsBidiPresUtils::ReorderFrames we don't need a BidiLineData at all if there's only
a single frame on the line; we can just call RepositionFrame directly.
Differential Revision: https://phabricator.services.mozilla.com/D203124
This was done using bindgen's "emit_diagnostics" feature, which shows
unused allowlist entries.
Enabling it by default would need extra dependencies so for now don't.
Differential Revision: https://phabricator.services.mozilla.com/D203533
While we are computing the transform-box:stroke-box, for CSS Transforms or
Motion path Transforms, we have to avoid the cyclic dependency not only
for the SVG geometry frame itself, but also for the desendants of
the SVG container frame. Therefore, we just compute its fill-box (i.e.
make |getStroke| be false).
https://github.com/w3c/csswg-drafts/issues/9640
Differential Revision: https://phabricator.services.mozilla.com/D203184
These tests verify operator stretching for various stretchy or largeop
operators, by checking the `BoundingClientRect` of `<mo>` operators.
This is equivalent to existing more exhaustive checks that are done in
WPT, the difference is that here they are only relying on the fonts
pre-installed on the system. So export these tests assuming they are
checking some basic support with the default math font. Gecko is able
to use scale transforms to emulate operator stretching, so it always
pass the tests even when the system does not provide good math fonts.
Additionally, these tests are written as reftests, but are really only
doing some JavaScript checks, so rewrite them as testharness.js tests.
Differential Revision: https://phabricator.services.mozilla.com/D203399
These mstyle reftests verify that attributes on the mstyle element
have no effect and this is handled by existing WPT test
`legacy-mstyle-attributes.html`. So we just add the missing cases:
- mstyle-2.xhtml: This was removed from `reftest.list` by mistake in
D185270. `mspace` attributes are already covered, we add tests
for the `mpadded` attributes.
- `mstyle-3.xhtml`: most `mo` attributes are covered, we add the
missing case of the `form` attribute. Also tweak the test for the
`accent` attribute to avoid potential clash with `mover@accent`.
- `mstyle-4.xhtml`: These are tests for accent/accentunder
attributes on the mover/munder/munderover. Export them.
We also reword the note to stop saying we don't test mpadded or
accent/accentunder attributes on the munderover family of elements.
Differential Revision: https://phabricator.services.mozilla.com/D203151
These tests were introduced in bug 208309 and verify mirroring of some
basic operators in RTL mode, which Gecko implements in various ways
(Unicode character-level mirroring, RTLM glyph-level mirroring, scale
transform). This is currently not really defined in MathML Core so for
now keep them as internal WPT tests.
All tests but `mirror-op-1.html` uses a mismatch test approach: just
verify that the operator in RTL mode does render the same as the
operator in LTR mode. `mirror-op-1.html` is a match tests relying on
a `scaleX` transform to emulate mirroring, but that's not quite
reliable and it has many fuzzy annotations. So instead, we split it
into multiple mismatch tests similar to the other ones. This is a
weaker comparison but more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D203244
While we're there: also pull mColor's initialization out of the init list,
since it's the other member that's unconditionally initialized to a constant
value; and initialize it to 0 using the easier-to-interpret NS_RGBA macro
for setting nscolor values.
Differential Revision: https://phabricator.services.mozilla.com/D203214
Both Chrome and Safari override the sites autofill style.
Given that its crucial for users to be able to clearly see what Firefox autofills for
them, after discussing with UX, we decide also do the same.
Differential Revision: https://phabricator.services.mozilla.com/D202410
Both Chrome and Safari override the sites autofill style.
Given that its crucial for users to be able to clearly see what Firefox autofills for
them, after discussing with UX, we decide also do the same.
Differential Revision: https://phabricator.services.mozilla.com/D202410
<select> doesn't allow first-line, which was causing some non-fatal
asserts.
The annotated crashtest overflows a bSize but it gets handled safely by
nsLineLayout.
MANUAL PUSH: Trivial orange fix CLOSED TREE
This simplifies our combobox code a bit more:
* Reflow() is only needed to compute the label isize.
* Frame construction uses a setup more similar to <input type=file> to
get the right frame tree, removing a bunch of special code.
* Lots of special code removed all over the place.
Differential Revision: https://phabricator.services.mozilla.com/D203010
The CSS Box Sizing specification indicates that last remembered sizes
are recorded "at the time that ResizeObserver events are determined and
delivered" [1].
In bug 1807253, we changed the implementation of when proximity to the
viewport of `content-visibility: auto` nodes are determined and of when
resize observations are broadcast, in order to align with the latest
version of the HTML specification [2]. We continue to use an internal
`Document::mLastRememberedSizeObserver` to update last remembered sizes
but it has been causing issues (e.g. bug 1867090 and bug 1880928) and
could be replaced by a direct update before broadcasting resize
observations.
This is what the current patch is doing. The elements currently observed
by `Document::mLastRememberedSizeObserver` are now stored on a
`Document::mElementsWithLastRememberedSize` hashset and a new function
`Document::UpdateLastRememberedSizes` is called before broadcasting
resize observations, and peforms the work of `LastRememberedSizeCallback`
and of `CalculateBoxSize` (with `aBox=Content_box`).
The only behavior change is in the `while(true)` loop from
`DetermineProximityToViewportAndNotifyResizeObservers`: at each step
we update the last remember sizes for elements of arbitrary depth, and
don't use these depths for calculating `shallowestTargetDepth`. This is
fine, since our `LastRememberedSizeCallback` only records current box
sizes without causing significant side effects (e.g. execution of
JavaScript code) that may require a relayout.
[1] https://drafts.csswg.org/css-sizing-4/#last-remembered
[2] https://html.spec.whatwg.org/#update-the-rendering
Differential Revision: https://phabricator.services.mozilla.com/D202571
In order to create less WebRenderLayerScrollData currently we use a deferred transform item
https://searchfox.org/mozilla-central/rev/593c49fa812ceb4be45fcea7c9e90d15f59edb70/gfx/layers/wr/StackingContextHelper.h#82
We don't need a WebRenderLayerScrollData for every transform because a lot of transforms don't contain any ASRs, so the created WebRenderLayerScrollData would be useless.
However this optimization can lead to us creating a lot more WebRenderLayerScrollData later if the transform does contain ASRs. For example, if there is a transform, and then inside that is a ASR, and inside the ASR is a lot of small transforms, we end up having to create a WebRenderLayerScrollData for every little transform which don't contain any ASRs. This is doing the opposite of what the optimization intended.
WebRenderLayerScrollData creation happens during the CreateWebRenderCommands phase, so the display list build phase is complete, and we can tell cheaply if a transform contains any ASRs during display list building. So we just record that and use that to inform our decision about when to defer the transform item or not.
This optimization drastically reduces the total number of WebRenderLayerScrollData that we create during a full run of speedometer3 (summing the number created each paint over every paint). In my testing it went from 12-13k to 2-3k. Mostly subtests fell into two buckets: a single digit number of WebRenderLayerScrollData to begin with and this patch didn't change that, and 100 WebRenderLayerScrollData down to single digits after this patch. So the savings are concentrated in a few subtests that hit the described behaviour above.
I compared a profile before and after this patch of 10 runs of speedometer3, this patch saved 100 samples/ms serializing WebRenderLayerScrollData, which was what I expected based on how long serialization took before the patch combined with how many WebRenderLayerScrollData we were avoiding. The whole run took about 100,000 samples/ms, so this should hopefully be good for about 0.1% improvment. There is also potential savings in other areas outside of serialization step but that was a little harder to measure.
Differential Revision: https://phabricator.services.mozilla.com/D197446
Jonathan Kew
Norisz Fay
Otto Länd
Nicolas Chevobbe
Ting-Yu Lin
Mike Hommey
Gregory Pappas
Emilio Cobos Álvarez
Boris Chiou
Frédéric Wang
Timothy Nikkel
Dave Townsend
Peter Van der Beken
Robert Longson
Daniel Holbert
Natalia Csoregi
Dimi
Cristian Tuns