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
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
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
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 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
See discussion in
https://phabricator.services.mozilla.com/D272401#inline-1485354
We seem to rely on the timing of overflow containers display items for e.g.
Pagination.
DisplayList will be sorted by z-index, but it's a stable sort that relies on
items being added in document order.
`out-of-flow-in-multicolumn-paint-order-003.html` fails due to us not
fragmenting grid items needs fragmentation.
Differential Revision: https://phabricator.services.mozilla.com/D281028
Mark abspos next-in-flows with the `NS_FRAME_IS_PUSHED_OUT_OF_FLOW` bit, and
adjust the display item generation code accordingly.
In Bug 1994346, pushed abspos first-in-flow will get the bit as well.
Differential Revision: https://phabricator.services.mozilla.com/D277138
The asr of some display items depends on the items that it contains. When we do a partial display list update and we merge display list we can change what an item contains so we might have to update the asr of the item. UpdateASR performs this work. Unfortunately it doesn't quite do it correctly.
Items whose asr depends on the items that it contains will pick the asr that is an ancestor (or equal to) of the asr of every item that it contains. Additionally we want the asr to be an ancestor (or equal to) the initial asr for the item.
aContainerASR in UpdateASR contains the asr that is an ancestor of every contained item. So UpdateASR assumes that if the item is not a wrap list item that it wants the container asr as its asr. This is not correct. Additionally it assumes that if the item is a wrap list item (or subclass) that it wants the ancestor behaviour for it's asr. This is also not correct. What each display item wants for its asr is more complicated then that.
The pernosco session https://bugzilla.mozilla.org/show_bug.cgi?id=1764863#c1 gives an example of this going wrong. In that case the item is a transform item and it only contains items whose asr is a descendant of the asr of the transform item. The transform item is not a wrap list, so we set the asr of the transform item to a descendant of the asr that it should be.
To fix this we add a function to all display items that opts them in to this ancestor behaviour for asrs if they want it. Some display item types only want the ancestor behaviour in some cases so it can't just be based on the display item type. In making this change we need to look at all display item types that can return non-null from GetChildren (if they can't have children the asr won't change dynamically based on children/the contents). There are four such classes (and then all of their subclasses): nsDisplayContainer, nsDisplayTransform, nsDisplayPerspective, nsDisplayWrapList. In practice nsDisplayContainer is always Ancestor asr (but we still pass Ancestor at all places we create one). nsDisplayPerspective and nsDisplayTransform are always Constant asr. and nsDisplayWrapList has a very large tree of subclasses with various different behaviours of asr.
This also fixes a bug in UpdateASR: if aContainerASR is nothing then we should set the asr to the frame asr rather then early exiting.
Differential Revision: https://phabricator.services.mozilla.com/D262257
The root element no longer gets focus by default when tabbing, so this
code can only be triggered by making it explicitly editable or focusable in
some other way.
It's inconsistent with how we do :focus-visible, and hardcodes the style, so
remove it. This matches other browsers and authors can still show an outline if
they want to via the outline property.
Differential Revision: https://phabricator.services.mozilla.com/D260631
I haven't been able to reproduce this locally, but I see what's going
on, and I think we could do better.
This avoids the frame flush from nsCanvasFrame::CreateAnonymousContent,
and in general makes the anonymous content timing a lot more reasonable
(see the FlushPendingNotifications call that's getting removed).
The ServoStyleSet changes are needed now that there are multiple style
roots that can be unstyled like that.
It also simplifies the API as now it's not dependent on having a canvas
frame around (and thus doesn't need to flush layout).
Differential Revision: https://phabricator.services.mozilla.com/D250531
This restores the behavior that D242017 removed.
This is not per spec, and is mostly to avoid having to spend a lot of
time updating fuzzy annotations, but also de-risks the patch a little
bit, since the behavior should be the same as before.
Note that this is relatively well tested.
We need to change the time of the blending check to happen after
building the kid's display list, but on the flip side the "initial"
determination can be done upfront, so we can remove a few temporary
display lists.
Differential Revision: https://phabricator.services.mozilla.com/D242613
We no longer need it, as now it behaves just like a solid color.
This causes an expectation change in an internal windowUtils.elementFromPoint
test, due to the HitTest implementation, but it's not observable to the web
(the web APIs return null when off-screen rather than the root), and no other
internal callers depend on it.
Differential Revision: https://phabricator.services.mozilla.com/D242445
Always paint the scrolled canvas background if it's CSS-specified.
Compute the canvas background upfront so we don't need to walk the
display list after the fact.
This removes the scrolled canvas background in a few cases where the old
code could prove that it was not needed due to blending, see the
comment:
// To make layers work better, we want to avoid having a big non-scrolled
// color background behind a scrolled transparent background. Instead, we'll
// try to move the color background into the scrolled content by making
// nsDisplayCanvasBackground paint it.
It's unclear if that matters for performance with webrender nowadays,
but removing it does cause significant fuzzy failures, so it will be
reintroduced in a more explicit way in a follow-up patch.
Differential Revision: https://phabricator.services.mozilla.com/D242017
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
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
When we call nsCanvasFrame::BuildDisplayList from nsHTMLScrollFrame::BuildDisplayList there is already a compositor hit test item in it, created here https://searchfox.org/mozilla-central/rev/ff08e36e1f368bd193b54f569dbd79105b50f9a0/layout/generic/nsGfxScrollFrame.cpp#4146
If we create a blend container item in nsCanvasFrame::BuildDisplayList it puts everything that might already exist in the display list inside the blend container item. It should only do this for the background items that we just created as this is for background blend mode, we are only blending within the background of this frame.
In the fuzz testcase we then have a partial display list build that visits the root scroll frame (because a scroll bar is dirty), so it builds the compositor hit test item for the canvas frame (the child of the scroll frame), but canvas frame is not modified, so we don't descend into it, and we don't call nsCanvasFrame::BuildDisplayList, so the compositor hit test item does not get wrapped in the blend container, and thus it has moved in the display list without being marked modified.
Differential Revision: https://phabricator.services.mozilla.com/D209511
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
Also, remove the following because they are not used.
- #include "AccessibleCaretEventHub.h"
- #include "nsPrintfCString.h"
Differential Revision: https://phabricator.services.mozilla.com/D200529
The code no longer compiles because most of the functions such as
`EventStateManager::GetFocusedContent()`, `PresContext::GetContainer()`, and
`nsIDocShell::GetHasFocus()` are gone.
Differential Revision: https://phabricator.services.mozilla.com/D200528
ReflowInput's computed sizes and border&padding are stored in logical
coordinates, so accessing the physical version is slower [1]. This patch
converts as many callers as possible to use logical coordinates.
This patch doesn't change behavior.
[1] For example, accessing `ComputedWidth()` and `ComputedHeight()` needs two
`IsVertical()` check, but `GetPhysicalSize()` only needs one.
Differential Revision: https://phabricator.services.mozilla.com/D200237
Those callers who using the pointer immediately after getting from
`GetPresShell()` can be replaced with `PresShell()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D199164
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
Masayuki Nakano