This causes a typedef mozilla::ServoElementSnapshot ServoElementSnapshot; to be
created, which we rely on bindgen not generating.
But bindgen will start (correctly) generating it in:
https://github.com/rust-lang/rust-bindgen/pull/1436
So easiest fix is just to remove this typedef, since it's just used by one FFI
function.
This causes a typedef mozilla::ServoElementSnapshot ServoElementSnapshot; to be
created, which we rely on bindgen not generating.
But bindgen will start (correctly) generating it in:
https://github.com/rust-lang/rust-bindgen/pull/1436
So easiest fix is just to remove this typedef, since it's just used by one FFI
function.
The fuzzy() annotation here is using the max-difference from the
Windows failures in bug 1452527, and the number-of-mismatching-pixels
from mac/linux failures in bug 1503525.
--HG--
extra : rebase_source : b7261f2f150ec609cec7c1f08e1fa7459994ddf3
The example frame tree didn't survive the global clang-format change.
DONTBUILD because this is a comment-only change.
Differential Revision: https://phabricator.services.mozilla.com/D13602
--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
I'm pretty sure the FIXME I left in the outline-style code is a bug,
but I want to clean this up further and I didn't want to fix it without adding
a test.
Differential Revision: https://phabricator.services.mozilla.com/D12859
--HG--
extra : moz-landing-system : lando
This is all the style-system work needed for this.
This implements the concept of legacy shorthands, teaches tests to understand
it, and adds a few more tests for these properties in particular.
The WPT even caught a few WebKit / Blink bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=906336https://bugs.webkit.org/show_bug.cgi?id=191803
This doesn't change the layout behavior for page-break-before: always, since
it'd stop breaking in multicol and such. Similarly, break-before / break-after:
column and page still behave the same, I'll file followups for those given
comment 22.
Differential Revision: https://phabricator.services.mozilla.com/D12211
--HG--
extra : moz-landing-system : lando
This is consistent with what we do for non-stacking-contexts. The
GetCaretFrame() == child check may be able to go away, I'm not sure, so I've
left it for now.
Differential Revision: https://phabricator.services.mozilla.com/D13384
--HG--
extra : moz-landing-system : lando
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
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
