This is useful for nova (which wants to use a gradient border around the
selected tab and right now hack around it with multiple backgrounds).
For now enable only on chrome code by default since we only support
solid borders (which is what we want anyways), and we don't support
combining it with `background-clip: text`.
Differential Revision: https://phabricator.services.mozilla.com/D304960
Currently, `operator<<(std::ostram&, const nsINode&)` prints the path
of the node with some attribute information of each node. However, there
are some issues:
1. It's unclear if the reached root is a `DocumentFragment` or
`ShadowRoot` due to the same node name, `#document-fragment`.
2. Do not print the host's path.
3. Cannot print only in a specific node such as a `contenteditable`.
4. It's hard to consider which `Text` if a node has multiple `Text`
nodes.
5. No information about the assigned `<slot>`.
6. No information about `EditContext`.
This patch appends these information to each node. Additionally, adding
`format_as()` for avoiding to use `mozilla::ToString` for `fmt::format`
and `MOZ_LOG_FMT`.
Finally, to test the new data, this makes `Selection` and `SelectionAPI`
log use `MOZ_LOG_FMT`.
Differential Revision: https://phabricator.services.mozilla.com/D304964
mBuiltDisplayList, read via nsIDOMWindowUtils::CheckAndClearDisplayListState, is observed only by paint-regression tests: reftests and the mochitest helper_bug1669625.html. It was also being set during EventDelivery (hit-testing) display list builds, which nsLayoutUtils::GetFramesForArea performs to find the target frame when delivering a mouse or pointer event. That made those tests intermittently observe a display list build that was really just event hit-testing, unrelated to painting. Gate the three build-time SetBuiltDisplayList(true) calls on nsDisplayListBuilder::IsForPainting() so only painting and print builds record the flag.
Also add a mochitest asserting that hit testing (elementFromPoint) does not mark the document element's display list as built, while painting does.
Differential Revision: https://phabricator.services.mozilla.com/D303633
Also adds WPT reftests to validate alignment behavior in horizontal and vertical
writing modes with the different `alignment-baseline` values. Additionally:
- The `alignment-baseline: middle` tests have failing expectations. This is
because the existing implementation does not match the css-inline-3 definition
(which the new WPTs follow). See Bug 2030203.
- The WidthTest-Regular.otf support font was updated to remove its unusual
ideographic-under baseline value, which affected its synthesized central
baseline. With the new support for `alignment-baseline: central`, this broke a
number of `text-combine-upright-compression-*` WPT reftests. The non-centered
baseline values were removed from this test using FontForge, so that the
synthesized central baseline matched the expectation of the test references.
Differential Revision: https://phabricator.services.mozilla.com/D292136
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
This reverts commit 482c9f881b.
Revert "Bug 2029869 - Synthesize vertical font metrics/baselines from horizontal metrics/baselines. r=layout-reviewers,jfkthame"
This reverts commit 8699ee2727.
Also adds WPT reftests to validate alignment behavior in horizontal and vertical
writing modes with the different `alignment-baseline` values. Additionally:
- The `alignment-baseline: middle` tests have failing expectations. This is
because the existing implementation does not match the css-inline-3 definition
(which the new WPTs follow). See Bug 2030203.
- The WidthTest-Regular.otf support font was updated to remove its unusual
ideographic-under baseline value, which affected its synthesized central
baseline. With the new support for `alignment-baseline: central`, this broke a
number of `text-combine-upright-compression-*` WPT reftests. The non-centered
baseline values were removed from this test using FontForge, so that the
synthesized central baseline matched the expectation of the test references.
Differential Revision: https://phabricator.services.mozilla.com/D292136
Same implementation over two different compilation units advocate for
promotion to a method.
This also prevents conflicts in the generalization of unified build.
Differential Revision: https://phabricator.services.mozilla.com/D298968
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
Moved ReflowInput::BreakType enumuration outside ReflowInput class to mozilla::BreakType, and refactored the functions using it to reflect the change.
Differential Revision: https://phabricator.services.mozilla.com/D298034
`EventStateManager::mGestureDownContent` needs to be a `Text` if the
drag gestures started from the `Text` even though the event target
should be its parent element. The reason is, various places maintain
`Selection` with the `Text` node.
On the other hand, `nsIFrame::MoveCaretToEventPoint` considers whether
it's in a drag gesture with checking `mGestureDownContent` is different
from its `mContent`. However, this is not enough if the text frame is
reframed by a `mousedown` listener. In that case, we handle the
`eMouseDown` event with the parent element's frame. Therefore, current
code does not work with the editable `Text` in `<input>` and
`<textarea>` (the drag starting to select from start of the `Text` and
cannot collapse the non-collapsed selection). Therefore, we should
check whether the frame content is different from the parent element of
`mGestureDownContent` too.
Differential Revision: https://phabricator.services.mozilla.com/D297855
Prefer aspect-ratio to the tentative BSize if we have both tentative
ISize and BSize.
Also make auto aspect-ratio handling a bit more explicit.
To prevent some regressions, we need to:
* Fix size-containment aspect ratio for <embed> (nsSubDocumentFrame).
* Fix RasterImage::GetIntrinsicRatio with uneven ratios.
* Avoid SVG root from using the aspect ratio from the viewbox, see
bug 2035918.
Differential Revision: https://phabricator.services.mozilla.com/D296982
will-change doesn't mean it is changing. We already did the same thing
for opacity years ago in bug 1754834.
will-change is useful to prevent side effects when the property changes
(like going from being a containing block for fixed-pos descendants to
not being it).
Given its limited extra effect and the complexity involved, let's remove
it.
We allow it to keep prerendering, since that is actually tested, and
seems worth doing.
Differential Revision: https://phabricator.services.mozilla.com/D228650
This reverts commit 656073d672.
Revert "Bug 2029867 - Unify synthesis of margin-based and content/padding/border-based box baselines. r=layout-reviewers,dshin"
This reverts commit 40a9b5db71.
Revert "Bug 2029864 - Adjust 1083848-3-inline-background-repeat.html with more robust font size handling. r=layout-reviewers,dshin"
This reverts commit 708a2904ee.
Revert "Bug 2029864 - Adjust 1115916-1-vertical-metrics.html reftest with more robust Ahem font size. r=layout-reviewers,dshin"
This reverts commit 677a5812f8.
Revert "Bug 2029864 - Adjust WPT tests for text-emphasis line heights. r=layout-reviewers,dshin"
This reverts commit c50c152a44.
This reverts commit 57ab38fd30.
Revert "Bug 2029867 - Unify synthesis of margin-based and content/padding/border-based box baselines. r=layout-reviewers,dshin"
This reverts commit 2c125c7bae.
Revert "Bug 2029864 - Adjust 1083848-3-inline-background-repeat.html with more robust font size handling. r=layout-reviewers,dshin"
This reverts commit 79a72f0bba.
Revert "Bug 2029864 - Adjust 1115916-1-vertical-metrics.html reftest with more robust Ahem font size. r=layout-reviewers,dshin"
This reverts commit 1e038f073e.
Revert "Bug 2029864 - Adjust WPT tests for text-emphasis line heights. r=layout-reviewers,dshin"
This reverts commit bf7b7bf2d3.
StickyScrollContainer only needs to track the primary frame; continuations and
IB-split siblings should not be registered. Move the registration from
DidSetComputedStyle into HandlePrimaryFrameStyleChange, which is called only
for primary frames, making the IsFirstContinuationOrIBSplitSibling check
unnecessary.
This also fixes the original crash: DidSetComputedStyle(nullptr) fires during
InitAndRestoreFrame before IB-split bits are set, so
IsFirstContinuationOrIBSplitSibling incorrectly returns true for non-first
IB-split siblings. Those stale StickyScrollContainer entries triggered an
assertion when new frames were allocated at the same address.
Differential Revision: https://phabricator.services.mozilla.com/D294555
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
When reframed, our frame selection might be reinitialized, losing the
drag state. Fix that up. A bit hacky, better ideas welcome, but I think
it's ok.
Differential Revision: https://phabricator.services.mozilla.com/D292907
When reframed, our frame selection might be reinitialized, losing the
drag state. Fix that up. A bit hacky, better ideas welcome, but I think
it's ok.
Differential Revision: https://phabricator.services.mozilla.com/D292907
Emilio Cobos Álvarez