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
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
It returns `nsresult` and has out-param for returning
`nsISelectionController*`. However, no caller of it handles differently
when this returns error vs. `nullptr` for `nsISelectionController*`.
Therefore, this should return `nsISelectionController*` simply.
Then, we don't need the same name method in the derived class,
`nsTextControlFrame`.
Differential Revision: https://phabricator.services.mozilla.com/D274880
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
`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
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
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
It's a rather useless interface:
* nsITextControlFrame is only implemented by nsTextControlFrame, so we
can just use that.
* nsIFormControlFrame had very few actual functionality, mostly
scattered around:
* SetFormProperty(select) was only useful for nsTextControlFrame.
* SetFormProperty(value) was only called on file controls.
* SetFocus() did mostly nothing, or things that can be done in
ElementStateChanged instead.
There are some do_QueryFrame calls that I replaced for better checks in
font inflation and nsIFrame, but I'll adjust to preserve behavior if you
insist (it just such a somewhat-random check).
Differential Revision: https://phabricator.services.mozilla.com/D217322
This is needed because we want implicit width of number and text
controls be the same, but explicit width be different to account for the
spinners. See:
data:text/html,<input type="number"><br><input type="text"><br><input type="number" min="1" max="9"><br><input type="text" size="1">
For example. This patch on its own shouldn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D215549
Split out from the other patch for readability. This doesn't change
behavior but unifies where we store the buttons of
number/search/password inputs.
Differential Revision: https://phabricator.services.mozilla.com/D215548
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
The removed reftsts test basically the opposite, and are sufficiently
covered by the WPTs that we start passing, so just remove them.
Differential Revision: https://phabricator.services.mozilla.com/D204797
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
This shouldn't change behavior, but it packs the two arguments to
DestroyFrom into a single thing, and makes nsIFrame::Destroy not so easy
to call without a previous context.
This is a prerequisite to pass aDestroyContext to various things that
right now just mint one, which can cause badness, see bug 1851787 and
related bugs.
It's also a bit nicer to add things there if we need to in the future.
Differential Revision: https://phabricator.services.mozilla.com/D187578
Tests are added as tentative, because the behaviour when there's no content,
or when there's placeholder text, seem very differnt for each browser.
Differential Revision: https://phabricator.services.mozilla.com/D185958
Tests are added as tentative, because the behaviour when there's no content,
or when there's placeholder text, seem very differnt for each browser.
Differential Revision: https://phabricator.services.mozilla.com/D185958
It is always called from TextControlState, and always ends up in
TextControlState::ValueEquals, so we can avoid some indirection and just
use that.
Depends on D183282
Differential Revision: https://phabricator.services.mozilla.com/D183283
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Some baseline exports are context-sensitive. One example: In line-layout scenario,
the last baseline of a scroll container is always the margin-end. In other (e.g.
flex, grid) scenarios, it's the border-box clamped offset to the last line in the
container.
This enables the required 3 different behaviours for `inline-block` scroll containers
for 3 different `baseline-source` values:
- `auto`: Last baseline, margin-end
- `first`: Border-box clamped offset to the first line
- `last`: Border-box clamped offset to the last line
Differential Revision: https://phabricator.services.mozilla.com/D173886
Emilio Cobos Álvarez