The main difference is that removals get processed before other
observers, like PresShell does. This prevents the options list from
getting re-filled, see the stack in the bug.
While at it, simplify the aria attribute notifications, they don't need
to walk the whole chain, as only DocAccessible cares about it. Route
them through the accessible service like the AttrElement ones.
Differential Revision: https://phabricator.services.mozilla.com/D304716
The main difference is that removals get processed before other
observers, like PresShell does. This prevents the options list from
getting re-filled, see the stack in the bug.
While at it, simplify the aria attribute notifications, they don't need
to walk the whole chain, as only DocAccessible cares about it. Route
them through the accessible service like the AttrElement ones.
Differential Revision: https://phabricator.services.mozilla.com/D304716
After a top-level navigation, the new PresShell has no per-PresShell mouse state until a real mouse event arrives. PresShell::SynthesizeMouseMove bails on that empty state, so a JS-driven cursor or :hover change (e.g. `body.style.cursor = 'none'` triggered by a keypress) does not take effect until the user moves the mouse.
PointerEventHandler still holds the static last-mouse state from before the navigation. When the previous owning PresShell has been torn down, claim that state for the new PresShell. The existing path in ProcessSynthMouseMoveEvent then dispatches a synthetic eMouseMove at the cached position.
Gate the claim with three checks. Skip if another live PresShell still owns the state (e.g. a popup). Skip unless the widget that originally recorded the state matches aRootPresShell's widget, since PresShell::IsRoot() means root of the in-process presContext tree and the previous owner could have been on a different top-level window in the same content process. And use a new sLastMousePointerId static for the recovered pointerId, since sLastPointerId tracks any pointer (including touch) and would mismatch the eMouseMove dispatched downstream.
Differential Revision: https://phabricator.services.mozilla.com/D301688
After a top-level navigation, the new PresShell has no per-PresShell mouse state until a real mouse event arrives. PresShell::SynthesizeMouseMove bails on that empty state, so a JS-driven cursor or :hover change (e.g. `body.style.cursor = 'none'` triggered by a keypress) does not take effect until the user moves the mouse.
PointerEventHandler still holds the static last-mouse state from before the navigation. When the previous owning PresShell has been torn down, claim that state for the new PresShell. The existing path in ProcessSynthMouseMoveEvent then dispatches a synthetic eMouseMove at the cached position.
Gate the claim with three checks. Skip if another live PresShell still owns the state (e.g. a popup). Skip unless the widget that originally recorded the state matches aRootPresShell's widget, since PresShell::IsRoot() means root of the in-process presContext tree and the previous owner could have been on a different top-level window in the same content process. And use a new sLastMousePointerId static for the recovered pointerId, since sLastPointerId tracks any pointer (including touch) and would mismatch the eMouseMove dispatched downstream.
Differential Revision: https://phabricator.services.mozilla.com/D301688
When scrollIntoView() is called on a position:fixed element that is already
visible in the visual viewport, ScrollFrameIntoVisualViewport() was still
calling ScrollToVisual() unnecessarily, causing a spurious visual scroll.
Add a check to skip the visual scroll if the element's rect (converted to
layout coordinates) is already contained within the current visual viewport.
Using layout coordinates is necessary since the visual viewport may have been
panned from the origin, in which case a viewport-origin check would give a
false negative for elements positioned beyond the visual viewport height.
Differential Revision: https://phabricator.services.mozilla.com/D297842
Previously, GetVisualViewportSize() returned the raw mVisualViewportSize, so
callers via ScrollContainerFrame::GetVisualViewportSize() were unaware of the
dynamic toolbar state. The toolbar awareness logic that was inline in
VisualViewport.cpp is moved into GetVisualViewportSize() itself, so all callers
get the correct size when the toolbar is collapsing or collapsed.
Differential Revision: https://phabricator.services.mozilla.com/D297841
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
The previous change collapsed the auto fallback to a fixed pair (Start for
the physical vertical axis, Nearest for the physical horizontal axis), which
matches the spec defaults (block: start, inline: nearest) only in horizontal
writing modes. In vertical writing modes the physical-to-logical mapping is
reversed, and in vertical-rl the block-axis default is "end" rather than
"start".
Compute the auto defaults for the physical vertical and horizontal axes
upfront in ScrollFrameIntoView, taking the target's writing mode into account
when AxesAreLogical is set, and pass them through ScrollToShowRect to
GetApplicableWhereToScroll. This keeps GetApplicableWhereToScroll free of any
writing-mode awareness.
This fixes the
testing/web-platform/tests/css/css-overflow/scrollbar-gutter-scroll-into-view.html
failure.
Differential Revision: https://phabricator.services.mozilla.com/D299089
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
Add "auto" to ScrollLogicalPosition per https://github.com/w3c/csswg-drafts/issues/9576.
Fragment navigation now passes WhereToScroll::Auto so that scroll-snap-align is
respected when present, falling back to the spec defaults (start for block,
nearest for inline) when absent. Explicit scrollIntoView() alignment values are
no longer overridden by snap alignment.
GetScrollSnapAlignFor previously returned None for all axes when the scroll
container had scroll-snap-type: none. Remove that early return so that fragment
navigation (which uses WhereToScroll::Auto) can still honor the target's
scroll-snap-align even on non-snapping containers, as the spec permits.
Differential Revision: https://phabricator.services.mozilla.com/D298959
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
Cosmin Sabou