This refactors the `::picker-icon` to be a generated content tree
abiding pseudo, rather than an element backed. This is in order for us
to support the specified `content:` UA styles.
This change also introduces said UA styles.
Differential Revision: https://phabricator.services.mozilla.com/D304450
This reverts commit 739a225b8a.
Revert "Bug 2041004 - Make ::picker-icon generated content, add UA styles r=layout-reviewers,firefox-style-system-reviewers,emilio"
This reverts commit 4b7b2a4083.
This refactors the `::picker-icon` to be a generated content tree
abiding pseudo, rather than an element backed. This is in order for us
to support the specified `content:` UA styles.
This change also introduces said UA styles.
Differential Revision: https://phabricator.services.mozilla.com/D304450
This reverts commit 6b8775f47f.
Revert "Bug 2041004 - Make ::picker-icon generated content, add UA styles r=layout-reviewers,firefox-style-system-reviewers,emilio"
This reverts commit e3529d76f3.
This refactors the `::picker-icon` to be a generated content tree
abiding pseudo, rather than an element backed. This is in order for us
to support the specified `content:` UA styles.
This change also introduces said UA styles.
Differential Revision: https://phabricator.services.mozilla.com/D304450
This reverts commit b434b10988.
Revert "Bug 2041004 - Make ::picker-icon generated content, add UA styles r=layout-reviewers,firefox-style-system-reviewers,emilio"
This reverts commit e92bda8433.
This refactors the `::picker-icon` to be a generated content tree
abiding pseudo, rather than an element backed. This is in order for us
to support the specified `content:` UA styles.
This change also introduces said UA styles.
Differential Revision: https://phabricator.services.mozilla.com/D304450
This refactors the `::picker-icon` to be a generated content tree
abiding pseudo, rather than an element backed. This is in order for us
to support the specified `content:` UA styles.
This change also introduces said UA styles.
Differential Revision: https://phabricator.services.mozilla.com/D304450
The bug happens when we reconstruct the abspos element inside the IB-split
block-wrapper where the inline element is an absolute containing block.
In `GetAbsoluteContainingBlock()`, when `absPosCBCandidate` is the
`MozBlockInsideInlineWrapper`, redirect the candidate to the first IB-split
sibling that is the absolute containing block. Otherwise, the function will
continue going up the parent chain until it finds `nsCanvasFrame` (the initial
containing block).
Differential Revision: https://phabricator.services.mozilla.com/D303124
This matches WebKit and our previous behavior.
These are replaced elements and those generally don't support them. It's
not defined that these elements are block containers, we just switched
to implement them as such.
Differential Revision: https://phabricator.services.mozilla.com/D300559
This code comes all the way back from bug 480979.
What happens here is as follows:
* There are two table-column items, with their relevant anonymous
wrapper. Why the page uses `display: table-column` for this escapes
my understanding.
* We insert the header next to them. We compute the parent frame to be
the (anonymous) nsTableColumnGroup frame, because it's our sibling's
parent.
* We decide you're not a column, and thus you get suppressed. We don't
create FrameConstructionItems for it.
* We don't realize in WipeContainingBlock that things went wrong, and
fail miserably.
Fortunately we can tweak this to perform the suppression later in the
pipeline.
Differential Revision: https://phabricator.services.mozilla.com/D295265
Boolean parameters are opaque at call sites. AllowCounters::Yes/No makes
the intent clear without consulting the function signature.
Differential Revision: https://phabricator.services.mozilla.com/D294554
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
This also should fix bug 1881942 (placeholder is now scrollable
alongside the textarea).
This makes nsTextControlFrame a subclass of ScrollContainerFrame (with
an inner block), and tweaks layout to match.
It lays out the inner content using block layout and align-content,
rather than bespoke reflow primitives. This makes field-sizing trivial
to implement on top.
This is a bit scary, but simpler in most ways. In particular, it needs
to teach ScrollContainerFrame of the button, because that goes outside
the scrollable area, like scrollbars. That said it needs less
special-cases added than those removed, and it should also be faster
(needs less frames to layout an input with placeholder etc), and match
other browsers better.
The general set-up is:
<text-control-editing-root/>
<placeholder/>
<autofill-preview/>
text-control-editing-root is always inline-block and always displayed
(since it's what grabs the focus / shows the caret). If the
autofill-preview or placeholder are displayed, the editing-root is
zero-width and clipped (note that for placeholder that's guaranteed
because placeholder is only shown with an empty value, but
autofill-preview needs it).
placeholder and autofill-preview are hidden via `display` rather than
visibility. This doesn't make a difference with this patch but it
matters for bug 1977176.
Caret painting needs an extra hop to paint atop the placeholder (no
observable behavior change, but worth calling out).
There is one subtle behavior change, which is that single-line inputs
never report scrollable overflow in the block axis. This matches other
browsers (see the tweak in nsBlockFrame's overflow computation) and is
needed to avoid regressing scrollable-overflow-padding-input.html.
The changes in window_composition_text_querycontent.xhtml are needed
because before this patch, the height of the control editing root was
always the height of the whole textarea. The characters you're composing
might legitimately be taller than the line. Bump the line height so that
that doesn't happen in this test.
Differential Revision: https://phabricator.services.mozilla.com/D293666
They never inherit anything (except background, but that is a no-op
because viewport inherits from nullptr, which is the initial style).
It seems in the past we relied on recomputing some of this for direction
propagation or so, according to the comments, but that's definitely no
longer true.
Also the comment about needing overflow: auto is wrong, because we've
since always created scrollbars for the root (and avoided reframes).
Similarly, the assertion about viewport is kinda unnecessary. It was
introduced in:
https://hg.mozilla.org/mozilla-central/rev/8fd06045940a05d56d833a0488262fe2279d3702
But since then we always skip fixup for all anon boxes anyways, and
specify display: block explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D293710
They never inherit anything (except background, but that is a no-op
because viewport inherits from nullptr, which is the initial style).
It seems in the past we relied on recomputing some of this for direction
propagation or so, according to the comments, but that's definitely no
longer true.
Also the comment about needing overflow: auto is wrong, because we've
since always created scrollbars for the root (and avoided reframes).
Differential Revision: https://phabricator.services.mozilla.com/D293710
This reverts commit 88008cd8ca.
Revert "Bug 2012637 - part 8: Make `nsContentUtils::ComparePoints` handle `TreeKind::Flat` and `TreeKind::FlatForSelection` correctly r=smaug,dom-core"
This reverts commit 73e6f6587b.
Revert "Bug 2012637 - part 7: Make `RangeUtils::CompareNodeToRangeBoundaries()` use `nsContentUtils::ComparePoints` with valid point in the tree r=smaug"
This reverts commit 6985d5e80f.
Revert "Bug 2012637 - part 6: Make `nsRange::CutContents()` convert the range boundaries to the ones in the DOM before comparing r=smaug"
This reverts commit 73b585af3d.
Revert "Bug 2012637 - part 5: Delete the default template parameter of `nsContentUtils::ComparePoints` and relatives r=smaug,dom-core"
This reverts commit 1a7f24e5b5.
Revert "Bug 2012637 - part 4: Make `nsContentUtils` use `nsIContent` for taking a child node as a parameter r=smaug"
This reverts commit a6ea8d6824.
Revert "Bug 2012637 - part 3: Add template `nsINode` API which can switch to call API from `TreeKind` r=smaug,dom-core,webidl"
This reverts commit a4211e9df0.
Revert "Bug 2012637 - part 2: Add `TreeKind::FlatForSelection` and change the template parameter of `ChildIteratorBase` to `TreeKind` r=smaug,dom-core"
This reverts commit 0241749ee7.
Revert "Bug 2012637 - part 1: Make `ChildIterBase` template class to re-implement `FlattenedChildIterator` for DOM, Flat and FlatForSelection TreeKind r=smaug,dom-core,layout-reviewers,emilio"
This reverts commit 9e71cb77fb.
Having two lists that the frame constructor is not aware is a quirk that
causes correctness issues like bug 2021043.
Instead, sort rowgroups and colgroups once in the common case during
table layout. This also fixed some visibility collapse things because
now we compute overflow just once after collapsing. It also caused some
unexpected passes in some editing tests.
Add a test for bug 2021043, which is fixed by this.
Differential Revision: https://phabricator.services.mozilla.com/D286457
`FlattenedChildIterator` is a non-template class and work only for the
flattened tree (i.e., in the `TreeKind::Flat` mode).
To centralize the implementation to access children from a parent node
in the various kinds of tree except `ShadowIncludingDOM`, this patch
makes it a template class and support the simple DOM (for
`TreeKind::DOM`), the flattened tree (for`TreeKind::Flat`) and also the
flattened tree for selection whose `TreeKind` will be added by the next
patch.
The reason why this patch does not support
`TreeKind::ShadowIncludingDOM` is, it is not clear that which children
should be handled when the parent is a shadow host, i.e., whether the
children of the host or the `ShadowRoot`. Therefore, the caller should
use `ShadowRoot` if the users want to list up the the children from a
host. Then, the code is really clear about what it does.
Differential Revision: https://phabricator.services.mozilla.com/D281303
Speedometer3's TodoMVC-jQuery hits basically the worst case of my
change, which is creating a hidden text input per row. That causes tons
of extra time spent in BindToTree and so on because we now create the
shadow tree for all of those. It is specially bad because the shadow
tree is particularly expensive (see bug 2017005).
For now, keep creating the <input> shadow tree lazily from layout, but
with a key difference: Once created, we keep it around.
This should still allow us to fix the reframing issues linked from
bug 2016280 and hopefully won't be too painful. It is a bit annoying
that TextControlElement can't rely on the shadow tree existing, but that
seems ok...
Of course preferred outcome is to make shadow trees less costly. Most of
the cost is still allocation of the slots, afaict from the profiles.
Differential Revision: https://phabricator.services.mozilla.com/D284039
There's still a ton of things that can be cleaned up after this, but
this setup is nicer.
For now, editor keeps getting set-up / torn down on BindToFrame. Seems
all that could be untangled, but step by step.
The preview stuff and placeholder can just be created on demand now,
rather than requiring frame reconstruction.
Also, nsSearchControlFrame and co no longer do anything of interest, so
move the still relevant bits elsewhere and remove them.
test_bug1248459.html is removed because it messes with the editor
selection using SpecialPowers, in a way such that it crosses shadow
boundaries, and messes up the selected state triggering debug asserts.
test_focus_docnav.xhtml now triggers a different code-path because of
the shadow root (rather than the frame tree traversal). Keep it working
for now by replacing it with something that isn't a shadow root.
Differential Revision: https://phabricator.services.mozilla.com/D282953
Popups are already regular abspos elements in the top layer,
these aren't necessary.
They are also abspos and fixed pos containing blocks
(via contain: paint).
Differential Revision: https://phabricator.services.mozilla.com/D282682
We already rely on one frame having at most one
absolute list, so there's no point in this distinction.
In the future, with position-visibility, we might want
to make fixed and abspos containing block effectively the same.
But one step at a time.
Differential Revision: https://phabricator.services.mozilla.com/D282681
Add exceptions for a few elements that do rely on their frame tree
size (mostly text controls). These are fixable but separate bug at the
very least.
Add reftests for <iframe> and <img>. Also, test all HTML elements in all
writing modes to ensure that they don't trigger assertions.
The <svg> case can't be easily reftested, afaict, because fullscreen
will change the size of the reftest window and <svg> doesn't support
popover.
Differential Revision: https://phabricator.services.mozilla.com/D282451
The situation this patch deals with is when you have the following frame
tree structure:
ns{Flex,Grid}ContainerFrame
::-moz-anonymous-item
Some text
And you append something after "Some text".
Before the regressing bug, we ended up in different codepaths for
insertion and append: Append always ended with the grid container as a
parent (and the anonymous item as a prev sibling), while insert ended
with the current nightly behavior of choosing the text frame as a
sibling, and the anonymous item as a parent.
WipeContainingBlock has code to deal with the wrong choice, but that
forces the container to be reconstructed, which is inefficient and in
cases like this one has correctness implications (because we store the
"view transition live capture bit" on the frame). I filed bug 2015007
for that since that's technically wrong too.
This is the relatively-minimal upliftable fix to minimize reframes in
both cases, which of course fixes the regression. I think it might be
worth looking into whether we can make the right decision later in the
pipeline (e.g., making WipeContainingBlock override the insertion parent
rather than bailing out). But that seems riskier.
Add a test for the different cases here.
Differential Revision: https://phabricator.services.mozilla.com/D282161
Keith Cirkel