29394 2016-01-26 18:49:21 +0000 Specify (or at least recommend) options for scrollIntoView call 2016-09-19 16:39:25 +0000 1 1 1 Unclassified Browser Test/Tools WG WebDriver unspecified PC Linux NEW P2 normal --- 20860 1 fisherii public-browser-tools-testing ato johnjan mike public-browser-tools-testing oldest_to_newest 124719 0 fisherii 2016-01-26 18:49:21 +0000 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. 124722 1 ato 2016-01-27 13:48:38 +0000 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. 127417 2 johnjan 2016-09-19 16:39:25 +0000 *** Bug 28935 has been marked as a duplicate of this bug. ***