Граф коммитов

3 Коммитов

Автор SHA1 Сообщение Дата
Hiroyuki Ikezoe b2485b123d Bug 1544060 - Use the root element's primary frame to get scroll-padding value. r=botond
Now the spec cleary says that we don't need to propagate body's
scroll-padding value to the document viewport since
https://github.com/w3c/csswg-drafts/issues/3740, so we don't need to care about
GetViewportScrollStylesOverrideElement() at all.

This change fixes the crash test case in this commit, but it's not sufficient.
In the next patch, we will fix another crash case.

Differential Revision: https://phabricator.services.mozilla.com/D27422

--HG--
extra : moz-landing-system : lando
2019-04-15 21:15:58 +00:00
Hiroyuki Ikezoe 5a15da458f Bug 1534070 - Factor scroll-margin into the position calculation where nsIPresShell::ScrollFrameRectIntoView() is going to scroll. r=botond
Depends on D23084

Differential Revision: https://phabricator.services.mozilla.com/D23085

--HG--
extra : moz-landing-system : lando
2019-04-11 06:22:31 +00:00
Hiroyuki Ikezoe 7b600a0531 Bug 1534070 - Factor scroll-padding into the position calculation where nsIPresShell::ScrollContentIntoView() is going to scroll if necessary. r=botond
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
2019-04-11 06:22:14 +00:00