The main goal of this patch is to ensure that we render the snapshots as
soon as the transaction is received on the WebRender to prevent another
transaction within the same vsync interval from replacing the old
state's transaction before it has had a chance to produce the snapshots.
In addition, we produce the snapshots by generating a frame that isn't
presented to the window. This is to avoid potential vsync issues from
trying to present multiple times in the same interval and avoids a fair
amount of wasted work.
Differential Revision: https://phabricator.services.mozilla.com/D242358
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 assertion can be hit when the pref was on and then got
flipped to off. I think this is a legit usecase to set it to null
even if the pref is off. So this assertion doesn't really make sense.
All the callers that set this to non-null have the pref check that
should be enough.
Differential Revision: https://phabricator.services.mozilla.com/D241996
While we are walking up the frame tree during for calculating the frame
bounds, there are cases that we reach to the top viewport frame. Thus
when we walk up the frame tree to invoke ScrollToShowRect for each
scroll container, we fail the check introduced in bug 1943865.
Just like we did in bug 1943865, this commit has also two tests, one is
a web platform test, the other is a mochitest. But unlike bug 1943865,
the mochitest in this commit doesn't use zoomToFocusedInput since
zoomToFocusedInput ends up calling another
PresShell::ScrollFrameIntoView call via Selection::ScrollIntoView [1], which
wallpapers this bug, i.e the mochitest will get pass without this proper
fix.
[1] https://searchfox.org/mozilla-central/rev/cb46268bc26b0cd9e91e625aa92aaa5a6f047b9d/dom/base/Selection.cpp#3654
Differential Revision: https://phabricator.services.mozilla.com/D240407
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
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
