Chrome dispatches `mousemove` event on the preceding `mouseover` target even if
the target is removed from the DOM tree. However, once the
"Boundary Event Dispatch Tracks Node Removal" feature is enabled, Chrome Canary
dispatches `mousemove` on the last deepest `mouseenter` event target which is
still connected. Therefore, we should follow their new behavior if it's simply
possible.
Note that if `pointeover` target is removed, Chrome does not dispatch
`pointermove` on the last deepest `pointerenter` target. Therefore, this patch
limits the behavior change only for `eMouseMove`.
Differential Revision: https://phabricator.services.mozilla.com/D235807
`nsFrameSelection::GetLimiter()` is not `nullptr` only when it's an instance for
an independent selection of a text control. In the case, it's set to the editor
root anonymous `<div>` of the text control. Despite the name, this is already
optimized only for this purpose in `nsFrameSelection::NodeIsInLimiters()`.
Thus, we don't have any problems to make this clearer for the other developers
with renaming some parameter names.
`nsFrameSelection::GetAncestorLimiter()` is also always an `Element`. So,
we can change this to `Element` too.
Differential Revision: https://phabricator.services.mozilla.com/D235254
There's a race condition where the keyboard height change notification
has arrived but nsDocumentViewer size change hasn't yet arrived.
MobileViewportManager::mPendingKeyboardHeight is introduced to fix the race.
Differential Revision: https://phabricator.services.mozilla.com/D234262
There's a race condition where the keyboard height change notification
has arrived but nsDocumentViewer size change hasn't yet arrived.
MobileViewportManager::mPendingKeyboardHeight is introduced to fix the race.
Differential Revision: https://phabricator.services.mozilla.com/D234262
`nsFrameSelection::NormalSelection()` returns a `Selection&`, which eliminates the need for nullptr check at call sites.
This simplifies the code in some places and removes unnecessarily indented blocks.
Differential Revision: https://phabricator.services.mozilla.com/D230583
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
Reuse the editor's manual NAC machinery for now, and hook it into
StyleChildrenIterator and co.
We might need to slightly tweak the setup for selector-matching, not
sure yet, but that should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D228255
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
Previously, scrolling start events always fired on an Accessible for an element, never a text leaf.
However, a text fragment starts in a text leaf node and there may be many other children of the parent element prior to the start of the text fragment.
We want to get a11y clients as close as possible to the fragment, so fire the event on the text leaf node instead.
Unfortunately, we can't fire the Windows event on text leaf nodes, so we have to override this to use the parent in Windows specific code.
Fortunately, we can expose the highlight on Windows via text attributes, so clients can find out exactly what is highlighted, albeit with a bit more work.
This text leaf change is of most benefit on Android, where we can't expose the highlight, but we can move accessibility focus to a text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D226587
Previously, scrolling start events always fired on an Accessible for an element, never a text leaf.
However, a text fragment starts in a text leaf node and there may be many other children of the parent element prior to the start of the text fragment.
We want to get a11y clients as close as possible to the fragment, so fire the event on the text leaf node instead.
Unfortunately, we can't fire the Windows event on text leaf nodes, so we have to override this to use the parent in Windows specific code.
Fortunately, we can expose the highlight on Windows via text attributes, so clients can find out exactly what is highlighted, albeit with a bit more work.
This text leaf change is of most benefit on Android, where we can't expose the highlight, but we can move accessibility focus to a text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D226587
