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
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
For now, replicate the label + icon structure.
Use pseudo-elements for them. We could use select.css instead, but we
need a way to to prevent the display fix-up from applying (this is
needed because otherwise <select style=display:flex> starts getting the
label and button on different lines), and pseudo-elements is easier.
Use a <span> for the icon since we basically otherwise have a hidden,
unfocusable button and it simplifies the styling that way.
Use the same for the input file content since it simplifies the logic on
the frame constructor.
nsListControlFrame gets some clean-up as well since I was trying to make
sense of nsISelectFrame, but I could split that out if needed.
Tests for bug 323656 fail now because it tests explicit inheritance from
the <select> to the <option>, and now that goes through a <slot>.
Other elements have the same issue, see
https://github.com/whatwg/html/issues/3748. So for now remove those
tests.
Differential Revision: https://phabricator.services.mozilla.com/D280041
No effective user visible behavior change, but this improves on the
previous state of things in a few ways. First, nsSelectsAreaFrame is
removed. This frame did three things:
* Calculated the row bsize at the end of reflow. We can move that to
nsListControlFrame::Reflow.
* Drew the focus navigation outline: We can move it to
ScrollContainerFrame and simplify a bit the logic while at it.
* Made events go to the list control. We could do that with CSS if
needed, but other browsers don't and no test seems to rely on it.
Secondly, nsDisplayListFocus now uses WebRender, avoiding slow fallback
code.
Differential Revision: https://phabricator.services.mozilla.com/D277704
No effective user visible behavior change, but this improves on the
previous state of things in a few ways. First, nsSelectsAreaFrame is
removed. This frame did three things:
* Calculated the row bsize at the end of reflow. We can move that to
nsListControlFrame::Reflow.
* Drew the focus navigation outline: We can move it to
ScrollContainerFrame and simplify a bit the logic while at it.
* Made events go to the list control. We could do that with CSS if
needed, but other browsers don't and no test seems to rely on it.
Secondly, nsDisplayListFocus now uses WebRender, avoiding slow fallback
code.
Differential Revision: https://phabricator.services.mozilla.com/D277704
Move it to ReflowFinished() (which ScrollContainerFrame manages for us).
The reason for this is that if you get reflowed twice in the same reflow
(which happens very often with grid or flexbox), we might queue a reset
if we don't get interrupted in the first, but get interrupted in the
second for example.
In general DidReflow is almost never what you want.
Differential Revision: https://phabricator.services.mozilla.com/D226124
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
These frames have very similar implementations in `GetMinISize()` and
`GetPrefISize()`. Therefore, add helpers to avoid code duplication. The helpers
are named `IntrinsicISize()` to match existing helpers in flex & grid container.
Drop "Get" in `GetIntrinsicISize()` for `nsFieldSetFrame` and
`nsComboboxControlFrame` to match our coding style because it always returns a
value.
Differential Revision: https://phabricator.services.mozilla.com/D216002
Change listbox block size calculations such that when field-sizing is content, the number of rows is used not the size attribute.
Differential Revision: https://phabricator.services.mozilla.com/D212984
The debug statements all require customized #define to enable. I don't feel it
is useful to leave code that is not compiled in the default debug build.
Differential Revision: https://phabricator.services.mozilla.com/D212192
This is a preparation to remove `#include "nsIScrollableFrame.h"` for
ScrollTimeline.cpp and ViewTimeline.cpp.
Move the implementation of `nsListControlFrame::GetMultiple()` to cpp. Keeping
it inline requires adding `#include "mozilla/dom/Element.h"` in the header, and
I don't feel the method is hot enough to be inlined.
Differential Revision: https://phabricator.services.mozilla.com/D211492
This is a preparation to remove `#include "nsIScrollableFrame.h"` for
ScrollTimeline.cpp and ViewTimeline.cpp.
Move the implementation of `nsListControlFrame::GetMultiple()` to cpp. Keeping
it inline requires adding `#include "mozilla/dom/Element.h"` in the header, and
I don't feel the method is hot enough to be inlined.
Differential Revision: https://phabricator.services.mozilla.com/D211492
The two macros are used in `GetPrefISize()` and `GetMinISize()` implementations.
After removing them, we could further simplify some implementations because we
don't need a `result` variable in many cases.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D206316
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
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
Masayuki Nakano