Adds an |UpdateType| parameter to UpdateResolution() to better separate the
pre-reflow and post-reflow logic.
Differential Revision: https://phabricator.services.mozilla.com/D13314
--HG--
extra : moz-landing-system : lando
* Call SetResolutionAndScaleTo() in just one place
* Call UpdateVisualViewportSize() in UpdateResolution() rather than
requiring the caller to do it (and on non-first paints, only call it
if the resolution has actually changed)
Differential Revision: https://phabricator.services.mozilla.com/D13313
--HG--
extra : moz-landing-system : lando
* Introduce helpers for converting between zoom and resolution
* Perform calculations in terms of zoom rather than resolution
Differential Revision: https://phabricator.services.mozilla.com/D13312
--HG--
extra : moz-landing-system : lando
Basically, we shouldn't have blacklist to disable web API. However, the
keypress event behavior changes are not standardized things. Therefore,
if some web developers realize that they need to change their apps when
it's too late for them, Firefox users need to use another browser for
such web apps for several weeks or more, and such things may make the users
switch their default browser. For avoiding such worst scenario, we should
take the blacklists and if we get such compatibility reports, we should
add the domains into the blacklist even in release channel.
Differential Revision: https://phabricator.services.mozilla.com/D13374
--HG--
extra : moz-landing-system : lando
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
In particular, in nsCharClipDisplayItem::IsSelected() we know that
the frame must be a nsTextFrame (or nsContinuingTextFrame) which
means nsTextFrame::IsFrameSelected() can be called directly now.
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
