It's an alias of `nsINode::GetClosestNativeAnonymousSubtreeRootParentOrHost()`
and oddly it returns `const nsIContent*` rather than `nsIContent*`. Therefore,
some callers need to use `const_cast`.
Differential Revision: https://phabricator.services.mozilla.com/D241776
Basically when getSelection().toString() is called, Chromium may
return an serialization on a different content than Firefox.
This patch tries to address this webcompat issue by mimicing
the same behaviour.
We should still address the spec issues, but this seems to be
an acceptable compromise.
Differential Revision: https://phabricator.services.mozilla.com/D239657
Basically when getSelection().toString() is called, Chromium may
return an serialization on a different content than Firefox.
This patch tries to address this webcompat issue by mimicing
the same behaviour.
We should still address the spec issues, but this seems to be
an acceptable compromise.
Differential Revision: https://phabricator.services.mozilla.com/D239657
The old "orthogonal limit" in ReflowInput was a rather ad hoc mechanism created
during the early implementation of writing modes, to avoid reflowing orthogonal
flows with unconstrained inline size. The spec has since been clarified to describe
the expected behavior in more detail, and we can dispense with the orthogonal-limit
concept and instead implement the constraints called for in the spec.
With this, we pass all the css-writing-modes/available-size-* tests (as well as
fixing a couple of other testcases that are dependent on this behavior).
Differential Revision: https://phabricator.services.mozilla.com/D241117
It's enabled in bug 1938528 and shipped in 135 5 weeks ago.
The pref makes the complicated code harder to read. Therefore, it's helpful
to get rid of this pref for the further work.
Differential Revision: https://phabricator.services.mozilla.com/D240815
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Don't have to write more one-off wrappers for size and margin.
It does cost having to copy fallback values, but that may
not be a huge tradeoff.
Differential Revision: https://phabricator.services.mozilla.com/D237097
Chrome dispatches `compositionend` before `mousedown` when there is a
composition and user clicks somewhere. However, we commit composition when
`EventStateManager::PostHandleEvent` moves/clears focus after `eMouseDown`
dispatching. Therefore, our `compositionend` event is fired after `mousedown`.
The Chrome's behavior is simpler than us from mouse button event handlers point
of view because it guarantees that there is no composition when handling mouse
button events. We should follow this behavior for better compatibility and
making the things simpler.
Differential Revision: https://phabricator.services.mozilla.com/D236827
In the case of position:fixed frame, walking up the frame tree doesn't
reach to the root scroll container, thus we need to invoke
ScrollToVisual outside the walking up the tree loop.
This commit has two independent tests, a web platform test and a
mochitest. Unfortunately the web platform test doesn't work on Firefox,
since WebDriver (GeckoDriver) doesn't support touch action yet. It works
on Chrome. What the mochitest does is mostly equivalent with the web
platform test, but with nsIDOMWindowUtils.setResolutionAndScaleTo and
zoomToFocusedInput.
Differential Revision: https://phabricator.services.mozilla.com/D236061
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
