This is probably something we want to move towards, so it doesn't hurt
adding a pref to allow people to experiment with it.
Differential Revision: https://phabricator.services.mozilla.com/D189919
Because we use NULL to indicate the auto value, once a page contributes a
non-auto page value then that will be all that is seen by ComputePageValue
when a later page doesn't have a page-name at all.
Actually checking for the page-name value will fix page-name values when
an empty/auto page-name follows pages with a non-auto value. It is also
slightly more efficient, as it avoids a frame property lookup and instead
just looks at the computed style.
While we are here, remove an assert that is clearly not possible to occur
anymore, and add a short explanation of the code in ComputePageValue.
Differential Revision: https://phabricator.services.mozilla.com/D188544
Implemented support for fallback values in CSS attr():
`attr(<attr-name>, <attr-fallback>)`
Full syntax supported as of this rev:
`[namespace? `|`]? ident [`,` fallback]?`
Spec: https://drafts.csswg.org/css-values-5/#attr-notation
Also added a new WPT reftest for attr fallback without a type,
and some new attr serialization WPTs (namespace and fallback).
Differential Revision: https://phabricator.services.mozilla.com/D176801
Instead of recalculating quotes and counter before destroying contain
style scopes, calculate them after. This prevents stale frame pointers
from sticking around during counter and quote recalculation.
Differential Revision: https://phabricator.services.mozilla.com/D188254
The subdocument call when there's no root frame is silly, because we
won't find a canvas frame and we'll end up with transparent.
This needs to tweak the canvas frame construction code to make canvas
anon content show up on the "top" canvas, not on the page content
canvas.
This can be simplified now, because the reason we had to build canvas
anon content before processing kids of the root frame (bug 1558352) no
longer applies since I made popups regular out-of-flow elements
(bug 1799343).
Differential Revision: https://phabricator.services.mozilla.com/D179461
This patch introduces functional pseudo parameters, i.e. `::highlight(foo)`,
for `getComputedStyle()`. This required adapting the parse algorithm (`nsCSSPseudoElements::ParsePseudoElement()`) and forwarding the functional pseudo parameter into the style engine.
Differential Revision: https://phabricator.services.mozilla.com/D183773
This commit removes the preference
mathml.legacy_maction_and_semantics_implementations.disabled
that controls whether we layout maction/semantics as an mrow +
extra style. It has been set to true since Firefox 106.
Differential Revision: https://phabricator.services.mozilla.com/D184720
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
We need to inline Self::new() so cbindgen generates the constants, which
is kinda lame, but seems better than duplicating the values and type
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D183921
The TLDR is that our first-line implementation is complete madness, but
I'm not fixing bug 1465474 yet.
The guarantee that first-line style reparenting relies on is that
reparenting shouldn't change reset properties (that's why we had all
this "style to inherit ignoring first-line" to inherit reset
properties). Bug 1839223 broke this guarantee in the case the mapped
attribute declarations are reused / mutated (which is something we want
to do for performance).
What's going on in the test-case is that the old style's rule-node
declarations are mutated by the mapped attributes code. Re-cascading the
old styles yields a different `float` property value.
When a style change that causes a reframe like this one happens, we
don't update the frame tree styles with the new styles: it'd be wrong
and also useless work.
First-line reparenting happens after we've recomputed the styles, but
before we've reframed as needed. In this intermediate state, the frame
remains with the old (floated) style, but the ::first-line reparenting
code isn't aware that this frame is going away, so it happily
re-cascades and updates the style anyways, creating a floated
frame that has float: none in its computed style information.
This causes the frame destruction code to crash.
This patch restores that guarantee that ::first-line doesn't change
reset properties by re-using the "reset properties cache" code-path.
This is also simpler since it avoids us having to compute the "parent
ignoring ::first-line" style.
The code is also more explicit with the new enum rather than just an
Option.
Differential Revision: https://phabricator.services.mozilla.com/D182769
The TLDR is that our first-line implementation is complete madness, but
I'm not fixing bug 1465474 yet.
The guarantee that first-line style reparenting relies on is that
reparenting shouldn't change reset properties (that's why we had all
this "style to inherit ignoring first-line" to inherit reset
properties). Bug 1839223 broke this guarantee in the case the mapped
attribute declarations are reused / mutated (which is something we want
to do for performance).
What's going on in the test-case is that the old style's rule-node
declarations are mutated by the mapped attributes code. Re-cascading the
old styles yields a different `float` property value.
When a style change that causes a reframe like this one happens, we
don't update the frame tree styles with the new styles: it'd be wrong
and also useless work.
First-line reparenting happens after we've recomputed the styles, but
before we've reframed as needed. In this intermediate state, the frame
remains with the old (floated) style, but the ::first-line reparenting
code isn't aware that this frame is going away, so it happily
re-cascades and updates the style anyways, creating a floated
frame that has float: none in its computed style information.
This causes the frame destruction code to crash.
This patch restores that guarantee that ::first-line doesn't change
reset properties by re-using the "reset properties cache" code-path.
This is also simpler since it avoids us having to compute the "parent
ignoring ::first-line" style.
The code is also more explicit with the new enum rather than just an
Option.
Depends on D182768
Differential Revision: https://phabricator.services.mozilla.com/D182769
They shouldn't be doing any work. The only views that exist now are
1) root views
2) menupopup frames
3) subdocument frames and the anonymous inner view directly below them.
The typical ReparentFrameView(List) calls happens during reflow moving something between next in flows. Menupopup frames can't have continuation frames so no next in flows. I audited every call site, none of them should be able to move something out of or into a menupopup frame, and of course none of them should be moving frames across a document boundary.
I left them in as debug only code with unreachable asserts; we can remove it after fuzzers verify that it is unused.
Differential Revision: https://phabricator.services.mozilla.com/D177863
nsCSSFrameConstructor::CreateContinuingFrame creates a frame based on the
result of nsIFrame::Type(). The regressing bug changed the nsFileControlFrame
type from Block to its own FileControlType type, which meant that we stopped
creating nsBlockFrame continuations for it.
Fix it by restoring the previous behavior: changing the Type() back to return
Block, and using QueryFrame instead to check for the specific
nsFileControlFrame where we need to.
This is all rather messy, see bug 1555477 for related discussion.
Differential Revision: https://phabricator.services.mozilla.com/D175062
Use a MiddleCroppingBlockFrame subclass that looks at the value attribute
instead. We don't need accesskey etc for these so we can just reuse it as is.
Differential Revision: https://phabricator.services.mozilla.com/D173669
We still have some remnants of XUL layout due to nsBox / nsLeafBoxFrame
which XUL trees / nsTextBoxFrame still use.
However all this code can go away before we get rid of those.
nsSplitterFrame was the last thing inheriting from nsBoxFrame.
Differential Revision: https://phabricator.services.mozilla.com/D173601
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
This rewrites scrollbar layout to work with regular reflow rather than
box layout.
Overall it's about the same amount of code (mostly because
nsScrollbarFrame::Reflow is sorta hand-rolled), but it cleans up a bit
and it is progress towards removing XUL layout altogether, without
getting into much deeper refactoring.
This also blocks some other performance improvements and refactorings I
want to make in this code.
We make some assumptions to simplify the code that to some extent were
made already before, both explicitly and by virtue of using XUL layout.
In particular, we assume that scrollbar / slider / thumb has no border or
padding and that the writing-mode is horizontal ltr.
Differential Revision: https://phabricator.services.mozilla.com/D173489
Factor a MiddleCroppingBlockFrame that does the double reflow shenanigans.
That should both be faster and easier to reason about. The only thing we need
to be careful about is to use the current inline coord from the line layout if
present to compute the real available isize.
Differential Revision: https://phabricator.services.mozilla.com/D173668
