This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In https://w3c.github.io/webdriver/webdriver-spec.html#elements it says: "An element is scrolled into view by calling scrollIntoView()." However scrollIntoView can take options (https://drafts.csswg.org/cssom-view/#extension-to-the-element-interface). Current implementations handle this differently: chromedriver and marionette appear to use "nearest" Selenium firefoxdriver appears to use "start" not sure about any other implementations These differences lead to reduced portability of tests, particularly in the presence of absolute positioned (or similar) elements on the page.
Marionette appears to use the ScrollLogicalPositions "end" and "nearest" for block- and inline elements, respectively. These are the defaults when you pass false as the only argument to scrollIntoView, if I’m reading the CSSOM spec you linked correctly. I definitely think we should call out explicitly what scrollIntoView should be called with though. What is a reasonable default here? I’m happy to go with {block: "end", inline: "nearest"} that Blink and Gecko appear to be using. --- As an aside I looked at how the scrollIntoView _atom_ is implemented: https://github.com/SeleniumHQ/selenium/blob/9e39b5619b2cbad5bfcf71d9ab57d17d762ec7af/javascript/atoms/action.js#L670 It appears to support passing a rectangle to scroll to, and support scrolling to nodes that don’t implement scrollIntoView. What nodes are these? Is this something we should take into account? It also does not scroll if the element is already in view.
*** Bug 28935 has been marked as a duplicate of this bug. ***