They have only `GetExplicitEventTargetContent` and some callers may want
to get proper target `Element`. Therefore, we should add them and the
common logic should be shared.
`nsListControlFrame::GetIndexFromEvent` looks for an inclusive ancestor
`<option>`. So, it can start the loop from its inclusive ancestor
element of the explicit event target so that it can use the new API.
Differential Revision: https://phabricator.services.mozilla.com/D300217
Most event targets an element node even if the input occurs on a `Text`.
`EventStateManager`, `PresShell`, `PresShell::EventHandler`, etc use
the result of `nsIFrame::GetContentForEvent` result as-is or looking
for proper ancestor element by the caller selves.
So, I think there should be `GetEventTargetContent()` which solves the
target node kind automatically and in the same way. And also this patch
renames `nsIFrame::GetContentForEvent` to
`nsIFrame::GetEventTargetExplicitContent` for consistency with
`Event::mExplicitOriginalTarget`.
Finally, this patch changes the callers which retrieves a parent
`Element` if the result of `GetContentForEvent` is not an `Element` to
use the new `GetEventTargetContent`.
The following patches make each caller of `GetContentForEvent` marked
with "FIXME" comment fix one by one.
Differential Revision: https://phabricator.services.mozilla.com/D297848
They have only `GetExplicitEventTargetContent` and some callers may want
to get proper target `Element`. Therefore, we should add them and the
common logic should be shared.
`nsListControlFrame::GetIndexFromEvent` looks for an inclusive ancestor
`<option>`. So, it can start the loop from its inclusive ancestor
element of the explicit event target so that it can use the new API.
Differential Revision: https://phabricator.services.mozilla.com/D300217
Most event targets an element node even if the input occurs on a `Text`.
`EventStateManager`, `PresShell`, `PresShell::EventHandler`, etc use
the result of `nsIFrame::GetContentForEvent` result as-is or looking
for proper ancestor element by the caller selves.
So, I think there should be `GetEventTargetContent()` which solves the
target node kind automatically and in the same way. And also this patch
renames `nsIFrame::GetContentForEvent` to
`nsIFrame::GetEventTargetExplicitContent` for consistency with
`Event::mExplicitOriginalTarget`.
Finally, this patch changes the callers which retrieves a parent
`Element` if the result of `GetContentForEvent` is not an `Element` to
use the new `GetEventTargetContent`.
The following patches make each caller of `GetContentForEvent` marked
with "FIXME" comment fix one by one.
Differential Revision: https://phabricator.services.mozilla.com/D297848
MakeAndAddRef ensures that the freshly-allocated object immediately gets a
refcount of 1 (before it's even passed to AddScriptRunner). This avoids
several potential footguns that otherwise exist with a zero-refcount
freshly-allocated object.
It also makes the ownership-transfer semantics more clear
(via the already_AddRefed type that it produces) - AddScriptRunner is taking
ownership of the object, rather than using it temporarily while the caller
maintains ownership.
Differential Revision: https://phabricator.services.mozilla.com/D299039
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
Make nsIHTMLCollection the first base for nsContentList and co, since
it's needed for WebIDL bindings to work properly and shouldn't change
behavior in practice.
Move the handling of selected option and validity to HTMLSelectElement's
mutation observer.
Differential Revision: https://phabricator.services.mozilla.com/D295818
Make nsIHTMLCollection the first base for nsContentList and co, since
it's needed for WebIDL bindings to work properly and shouldn't change
behavior in practice.
Move the handling of selected option and validity to HTMLSelectElement's
mutation observer.
Differential Revision: https://phabricator.services.mozilla.com/D295818
This reverts commit 85b2d0d3dd.
Revert "Bug 2022763 - Propagate owner global from input element to DOM files properly. r=dom-core,win-reviewers,smaug,gstoll"
This reverts commit ff40c521b2.
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
When a transformed absolute containing block fragments across multi-column,
abspos children could paint in the wrong column. This happened because the
abspos display item was built when its placeholder was encountered during
display list traversal, and the placeholder could end up in a different column
than where the abspos should paint.
Extend `DisplayPushedAbsoluteFrames` (now renamed to
`DisplayAbsoluteFramesNotBuiltByPlaceholder`) to also directly build abspos
frames whose placeholder lived in a different continuation subtree. Skip
building those abspos frames when they are later traversed via their
placeholders.
Differential Revision: https://phabricator.services.mozilla.com/D294312
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
When a transformed absolute containing block fragments across multi-column,
abspos children could paint in the wrong column. This happened because the
abspos display item was built when its placeholder was encountered during
display list traversal, and the placeholder could end up in a different column
than where the abspos should paint.
Extend `DisplayPushedAbsoluteFrames` (now renamed to
`DisplayAbsoluteFramesNotBuiltByPlaceholder`) to also directly build abspos
frames whose placeholder lived in a different continuation subtree. Skip
building those abspos frames when they are later traversed via their
placeholders.
Differential Revision: https://phabricator.services.mozilla.com/D294312
The current mozilla::ScrollAxis struct in PresShellForwards.h isn't a simple
axis enum. It carries information about where to scroll to along a specific
axis, and under what conditions that should happen. So 'ScrollAxis' isn't the
best name.
Now we're introducing WebIDL 'ScrollAxis' in bug 1350457:
https://drafts.csswg.org/scroll-animations-1/#scrolltimeline-interface
The extensive use of PresShellForwards.h's ScrollAxis in DOM code makes it
conflict with this new DOM enum. Rather than try to fix this through lots of
explitic namespacing, this patch renames PresShellForwards.h's ScrollAxis.
Differential Revision: https://phabricator.services.mozilla.com/D293485
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
Jonathan Kew