nsFrameSelection::CommonPageMove() is called only by
nsTextInputSelectionImpl::PageMove() and PresShell::PageMove(). So, this is
the only implementation of (Shift+) PageDown and (Shift+) PageUp.
This scrolls down/up the specific frame. However, this allows to scroll
outside of selection limiter, for example, even when an editing host is
focused, its parent scrollable element may be scrolled. This is same behavior
as Blink so that we should keep this behavior.
However, it also emulates to click same position after scroll and this behavior
is different from Blink. At this time, it does not check selection limiter and
then, nsFrameSelection::HandleClick() may reset selection limiter the scrolled
frame is a parent frame of the limiter.
Therefore, this patch makes it check if the scrolled frame is a parent of the
limiter, and if so, use result of GetFrameToPageSelect() to emulate a click
instead. The result won't be a parent of the limiter because it is used when
handling Shift + PageDown and Shift + PageUp which are always handled in the
limiter.
Differential Revision: https://phabricator.services.mozilla.com/D13202
--HG--
extra : moz-landing-system : lando
Even if there is no scrollable element is in focused editing host, its parent
scrollable element should be scrolled. However, focus shouldn't be moved and
selection ranges should be kept in the editing host.
Differential Revision: https://phabricator.services.mozilla.com/D13201
--HG--
extra : moz-landing-system : lando
The reftest in this commit fails without changing the default value. The test
image is shrunk too much.
Differential Revision: https://phabricator.services.mozilla.com/D13172
--HG--
extra : moz-landing-system : lando
This fixes the assertion, though not the test-case, but now I can debug the
test-case and also land it as failing for now.
What was happening is that we had two ASRs (for the canvas and for the <body>),
and we were creating scroll data for the CompositorHitTestInfo of the <body>
(which obviously didn't have any ancestor transform) and for the
nsDisplayTransform in the backface for which HasPerspective returns true for,
but which already had an ancestor transform for the frame for which
ChildrenHavePerspective returns true.
It may be less risky to force it for both, but this doesn't make anything fail.
Differential Revision: https://phabricator.services.mozilla.com/D13242
--HG--
extra : moz-landing-system : lando
Previously, WebRender was getting a rectangle for reference frames
and stacking contexts, and it had to carefully treat the origin of this rectange:
- by offseting all the items in a stacking context
- by negatively compensating the sticky frame scroll port according to the
parent reference frame origin
With this change, we stop providing any non-zero origins. Instead we accomplish
the same behavior using existing API primitives, such as reference frames:
1. when a stacking context has an origin, we push another reference frame for it
2. when computing the sticky frame scroll port, we take this origin into account
This slightly simplifies Gecko-WR API, but more importantly it would allow WR to
get rid of this logic (of handling origins), which in turn would allow to switch
the reference frames from push()/pop() model to just define(), like we do for
scroll/sticky frames already.
Differential Revision: https://phabricator.services.mozilla.com/D13081
--HG--
extra : moz-landing-system : lando
Turn all const lists and related attributes into cenums, to provide a
vague sense of type safety.
Depends on D11715
Differential Revision: https://phabricator.services.mozilla.com/D11716
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
This sends a sync IPC message to the compositor after each crashtest, to
ensure that any stuff inflight in the compositor settles down. In
particular this should round-trip through all of the relevant compositor
threads (i.e. for WebRender it should ensure the scene builder, render
backend, and renderer threads all get flushed).
Differential Revision: https://phabricator.services.mozilla.com/D13033
--HG--
extra : moz-landing-system : lando
By replacing nsWebBrowser's implementation of the
nsIBaseWindow.initWindow and nsIBaseWindow.create with a new static
nsWebBrowser::Create method we make it possible to pass arguments
directly when creating an nsWebBrowser, for example the opener
BrowsingContext. As a bonus we can do away with
nsWebBrowser::mInitInfo!
Differential Revision: https://phabricator.services.mozilla.com/D12634
--HG--
extra : moz-landing-system : lando
Changes for nsIDOMWindowUtils.getOMTAValue is in the next commit with come test
cases.
Differential Revision: https://phabricator.services.mozilla.com/D13001
--HG--
extra : moz-landing-system : lando
This patch also gives nsCSSFrameConstructor.h its own UniquePtr include (since
we have some UniquePtr usage there, but no include). Presumably it's already
getting the include indirectly (via some other header) right now, but it should
really include it directly if it uses the type directly.
(This leaves one nsAutoPtr usage in nsCSSFrameConstructor, for 'mNode'. We can
probably convert that one without too much trouble, but I'm not doing so yet,
in part because we intentionally leak that variable in one spot and I haven't
fully worked out the ownership transfer for that case.)
Differential Revision: https://phabricator.services.mozilla.com/D12992
--HG--
extra : moz-landing-system : lando
In each file touched by this commit, there were no mentions of nsAutoPtr
besides the #include.
I verified that the folder layout/base still builds successfully in
non-unified mode after this patch, too. So, none of these files are secretly
using nsAutoPtr and depending on some other .cpp file to provide the header.
Differential Revision: https://phabricator.services.mozilla.com/D12993
--HG--
extra : moz-landing-system : lando
It seems that other browsers don't allow 'pointer-events: none' on the root content,
and this can cause us interoperability issues.
Differential Revision: https://phabricator.services.mozilla.com/D12500
--HG--
extra : moz-landing-system : lando
When popping a dirty root, take the shallowest one first (so we reflow from
outer frames first, to avoid potential duplicate reflow of inner frames).
Prevent duplicate roots (to be reworked in a future bug).
Differential Revision: https://phabricator.services.mozilla.com/D9490
--HG--
extra : moz-landing-system : lando
As mDirtyRoots will be accessed through a more cohesive API, this patch hides
the storage details (nsTArray) -- but provides almost the same API for now.
Differential Revision: https://phabricator.services.mozilla.com/D9489
--HG--
extra : moz-landing-system : lando
