In the case where scroll-snap-type is specified for the scroll container, the
scroll-padding is also factored into in ScrollFrameHelper::ComputeScrollSnapInfo
which is called via ScrollFrameHelper::ScrollToWithOrigin. It doesn't double
the scroll-padding value, but it's actually redundant, we should avoid it.
We could separate the functionality of ScrollToWithOrigin, one is to scroll
to a given element, the other is to scroll to a given position. The former will
be used for Element.scrollIntoElement and relevant stuff, the latter will be
used for Element.scrollTo and relevant stuff. That's being said, as of now, we
have still the old scroll snap implementation, so the separation will introduce
complexity, the separation should be done once after the old implementation
removed.
There are 9 call sites of nsIPresShell::ScrollContentIntoView:
nsIPresShell::GoToAnchor
nsIPresShell::ScrollToAnchor
Element::ScrollIntoView
We definitely needs scroll-padding and scroll-margin for these functions.
nsCoreUtils::ScrollTo
This is used for Accesible::ScrollTo which scrolls to a given accesible node,
probably we should behave as what Element::ScrollIntoView does.
Accessible::DispatchClickEvent
Similar to the above, similated various mouse events on a given target node.
PresShell::EventHandler::PrepareToUseCaretPosition
PresShell::EventHandler::GetCurrentItemAndPositionForElement
Both are for context menu, we shouldn't consider scroll-padding and
scroll-margin.
nsFormFillController::SetPopupOpen
This is used for autocompletion popup, we shouldn't consider scroll-padding
and scroll-margin.
nsFocusManager::ScrollIntoView
This is bit unfortunate, we should use scroll-padding and scroll-margin
depending on call site of this function. Bug 1535232 is for this case.
cssom-view/scrollIntoView-scrollPadding.html which has some tests that is
actually testing scroll-padding with scrollIntoView passes with this change.
The reftest in this change is a test case that the browser navigates to an
element with specifying the anchor to the element.
Differential Revision: https://phabricator.services.mozilla.com/D23084
--HG--
extra : moz-landing-system : lando
There are 7 test cases in this commit.
- no-viewport.html
A test case that wider contents should be scaled down even if no viewport
meta tag exists.
- viewport-width.html
A test case that wider contents should be scaled down (i.e. fit to the
device screen).
- minimum-scale.html
A test case that the initial zoom value is clamped by minimum-scale.
- initial-scale-0.html
A test case that specified initial-scale value is less than the default
minimum scale value (0.1), in such cases we shrink the content to fit
the display size.
- initial-scale-100.html
A test case that specified initial-scale value is greater than the default
maximum scale value (10), in such cases we shrink the content to fit
the display size.
- initial-scale-1.html
A test case that the auto initial zoom calculation doesn't apply to the
documents specifying initial-scale.
- box-shadow.html
A test case that box-shadow-ed area isn't incorporated into the initial zoom
value.
Depends on D10197
Differential Revision: https://phabricator.services.mozilla.com/D10198
--HG--
extra : moz-landing-system : lando
Generally there isn't really much difference for painting on html/body
element vs. viewport, so it's probably not worth finer grained control
over when we should propagate and when not.
MozReview-Commit-ID: HK7DsQdz41D
--HG--
extra : rebase_source : 444277648b9b5ee9bc9d14f549b42f4147afbeb3
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
Since the ref-sample made by linux, the mac and windows platforms need fuzzy.
And on windows platform, the first frame is different to other platform, skip it first.
Android platform somehow can not load the video src.
MozReview-Commit-ID: A0VbEcNSmck
--HG--
extra : rebase_source : 266f0012d460b8fd6b62ac1d2878dc9aa686f9a8
These are all duplicated in testing/web-platform/, so the only reason to
keep them is that web-platform-tests don't yet run on every platform
that mochitests do. But they get in the way, so let's remove the ones
that are relatively unlikely to be platform-specific.
reftest is disabled on windows due to localized try readback errors that can't be reproduced.
MozReview-Commit-ID: 379PZsRE5d6
--HG--
extra : rebase_source : b990572c0f33860998eb5485824e417387d3e204
Our behavior on these tests is reasonably close to matching Chromium
thanks to the combination of patches 1, 3, and 4, and 5.
--HG--
extra : commitid : BzErQKgv86B