Removed the Reflow Input in nsIFrame. Added includes for ReflowInput as
necessary in cpp files. Also Forward Declared nsLineLayout in 3 header
files.
Differential Revision: https://phabricator.services.mozilla.com/D298203
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
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
And remove unused includes of nsGkAtoms.h in the process. The few
dependencies have been moved to ServoStyleConstsInlines.h
The used command to remove the now unused dependency was:
git grep -l nsGkAtoms.h | while read line; do grep -v nsGkAtoms.h $line | grep -q -E '\<nsGkAtoms\>' || sed -i -e '/nsGkAtoms.h/d' $line ; done
Differential Revision: https://phabricator.services.mozilla.com/D292697
Move more text editor handling to the DOM, and remove more dead layout
code.
We need to move NeedToInitializeEditorForEvent down to
TextControlElement since the eager initialization of textarea was
papering over stuff.
The change needed in test_bug300691-1.html is a progression, I think.
Plain focus() generally puts the caret at the start rather than the end.
Differential Revision: https://phabricator.services.mozilla.com/D285755
Move more text editor handling to the DOM, and remove more dead layout
code.
We need to move NeedToInitializeEditorForEvent down to
TextControlElement since the eager initialization of textarea was
papering over stuff.
The change needed in test_bug300691-1.html is a progression, I think.
Plain focus() generally puts the caret at the start rather than the end.
Differential Revision: https://phabricator.services.mozilla.com/D285755
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
I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
I looked at this because in bug 2014331 I need to mark more pseudos as
element-backed, and it's kinda silly the state our setup is in right
now.
This is all a somewhat historical mess, because in the old style system
pseudo-elements were just atoms, and we had that different types of atom
setup. The source of truth for these right now lives in a header macro
file, which isn't very flexible.
But now we have PseudoStyleType which represents both pseudos and anon
boxes, and is similar to the rust side PseudoElement enum.
Plus, the ::-moz-tree pseudo-elements are defined as anon boxes which
doesn't make any sense, so move them to pseudo-elements while at it.
Unify this in a similar way we treat CSS properties: Source of truth is
in pseudo_elements.toml / anon_boxes.toml, and we generate Rust and C++
as needed. This allows removing the nsStaticAtom subclass thing from
XPCOM, too.
This avoids some nasty duplication around which pseudos are pref-gated
and what not as well.
Differential Revision: https://phabricator.services.mozilla.com/D282076
It's only used to check the closest text control. We can abuse the fact
that nsTextControlFrame only has anonymous kids instead to make checking
for a containing text control fast in the common case.
Differential Revision: https://phabricator.services.mozilla.com/D268110
PrepareEditor initializes and sets up the DOM as well so there's no need
for doing it twice.
This causes a behavior change in test_bug1785739, but I think it's a
progression, as before there were two calls to find() that ended up with
the same range.
Differential Revision: https://phabricator.services.mozilla.com/D267437
Make the anonymous content creation synchronously so that we don't need
to update layout after-the-fact, and make editor creation lazy like we
do for <input>.
I think we should try to remove the trailing <br> for <textarea> after
this (just so that editor doesn't insert it). But this is green on try
and fixes the issue so worth landing incrementally.
Differential Revision: https://phabricator.services.mozilla.com/D267252
Instead, just don't propagate inline padding to single-line <input>
scrollers.
This causes one web-observable behavior change which is that the
scroll{Width,Left} of the <input> changes. However this seems the
right thing to do API-wise, the client area doesn't include the
inline padding.
If this causes compat issues, it should be easy to special-case in
Element::GetClientAreaRect (but I'm hoping that's not the case, given
only one test is affected, and is a test I wrote).
Differential Revision: https://phabricator.services.mozilla.com/D266788
No behavior change, but this saves some per-child work and conceptually
is the right thing to do. HidesContent() is non-trivial.
Add an assertion to make sure we don't enter BuildDisplayListForChild
at all if content is hidden.
I audited all the callers, and the ones I didn't touch can't have
content-visibility (things like the viewport / pages / etc).
Differential Revision: https://phabricator.services.mozilla.com/D265956
`MutationEvent_Bindings::MODIFICATION`,
`MutationEvent_Bindings::ADDITION` and `MutationEvent_Bindings::REMOVAL`
will be removed. Therefore, we need alternative `enum class` for that.
This patch makes `nsIFrame` and subclasses use the new one.
Differential Revision: https://phabricator.services.mozilla.com/D263053
This patch updates all occurrences of the type `nsTextFragment` into its new name, `mozilla::dom::CharacterDataBuffer`.
It also updates the includes, including sorting.
Differential Revision: https://phabricator.services.mozilla.com/D259867
The methods are now, `GetConstFrameSelection()` etc, but does not return
`const nsFrameSelection*`. I believe that `GetIndependentFrameSelection()` is
clearer than the old names.
And also this patch adds `IsIndependentSelection()` and
`GetIndependentSelectionRootParentElement()` to make some callers of
`GetLimiter()` easier to read.
For the consistency, `GetLimiter()` should be renamed too, but I already have
a patch doing it in bug 1954020 and it's bigger. Therefore, I leave it as-is
for now.
Differential Revision: https://phabricator.services.mozilla.com/D241774
That is, after this patch, the BRFrame's inline-size becomes zero.
This patch is based on the previous attempt [1] in this bug, and removes the
code added in Bug 1242781.
The test_bug1216483.html change is worth an explanation. Each sub-test verifies
the blinking cursor (caret) position after pressing down arrow key in an
contenteditable container. The expected position is to the right of the letter
"a". Before this patch, the `(anchorNode, anchorOffset)` was
`("element with '.second' style", 1)`. After this patch, it becomes
`("a", 1)`, which is a valid representation of the caret position and
matches Google Chrome's behavior.
[1] https://hg.mozilla.org/mozilla-central/rev/c3f1ab75ea51
Differential Revision: https://phabricator.services.mozilla.com/D238162
That is, after this patch, the BRFrame's inline-size becomes zero.
This patch is based on the previous attempt [1] in this bug, and removes the
code added in Bug 1242781.
The test_bug1216483.html change is worth an explanation. Each sub-test verifies
the blinking cursor (caret) position after pressing down arrow key in an
contenteditable container. The expected position is to the right of the letter
"a". Before this patch, the `(anchorNode, anchorOffset)` was
`("element with '.second' style", 1)`. After this patch, it becomes
`("a", 1)`, which is a valid representation of the caret position and
matches Google Chrome's behavior.
[1] https://hg.mozilla.org/mozilla-central/rev/c3f1ab75ea51
Differential Revision: https://phabricator.services.mozilla.com/D238162
This patch is based on the previous attempt [1] in this bug, and removes the
code added in Bug 1242781.
The test_bug1216483.html change is worth an explanation. Each sub-test verifies
the blinking cursor (caret) position after pressing down arrow key in an
contenteditable container. The expected position is to the right of the letter
"a". Before this patch, the `(anchorNode, anchorOffset)` was
`("element with '.second' style", 1)`. After this patch, it becomes
`("a", 1)`, which is a valid representation of the caret position and
matches Google Chrome's behavior.
[1] https://hg.mozilla.org/mozilla-central/rev/c3f1ab75ea51
Differential Revision: https://phabricator.services.mozilla.com/D238162
Eugeniusz Lewandowski