Repository navigation
Conversation
| <li><p>Let <var>inline</var> be the <code>inline</code> | ||
| property of <var>action object</var>. | ||
|
|
||
| <li><p><a>Scroll into view</a> <var>node</var> with |
There was a problem hiding this comment.
If we have a scrolling behavior of auto or smooth the scrolling will be asynchronous. We should wait until the scrolling is done before continuing dispatching the remaining actions.
There was a problem hiding this comment.
I assumed this is already covered by waiting for "pending asynchronous waits arising from the last invocation of the dispatch tick actions steps" after dispatching an action because scroll a target into view returns a Promise that resolves when scrolling is done.
@jgraham did I understand this correctly?
There was a problem hiding this comment.
You are probably right. But lets get a final review from James anyway.
There was a problem hiding this comment.
No you'd need to specifically say to asynchronously wait for that promise to resolve.
| <var>action</var>, and <var>actions options</var>:</p> | ||
|
|
||
| <ol class="algorithm"> | ||
| <li><p>Let <var>node</var> be the result of <a>getting the property</a> |
There was a problem hiding this comment.
Some lines up we use getting a property. What shall we use?
There was a problem hiding this comment.
Both getting the property and getting a property are used throughout the spec.
There was a problem hiding this comment.
Mind then filing a new issue so that we can get this cleaned-up?
d55acf1 to
9cbc5d6
Compare
|
|
||
| <p>A <a>key input source</a> supports the same <a>pause</a> action | ||
| as a <a>null input source</a> plus the following actions: | ||
| <p>A <a>key input source</a> supports the same <a>pause</a> |
There was a problem hiding this comment.
Why do these input sources support scrollIntoView? pause is a special case here because it's used as the no-op action.
There was a problem hiding this comment.
The action is not associated with any specific device, so I treated it like the pause action. Which input sources should we add it to? I think it makes most sense to add it to pointer actions because its main use case is to prepare for a click. Should we also add it to the null input source?
There was a problem hiding this comment.
null import source only. scrollIntoView works more like running script in that it doesn't cause any pointer events to be emitted, so it definitely isn't right for the pointer input source. In many ways it's not really an input action at all; the only reason to add it is because people want to use is as a precondition on other actions as part of the chain, and this is easier than defining a more general purpose mechanism to allow that.
| <li><p>Let <var>inline</var> be the <code>inline</code> | ||
| property of <var>action object</var>. | ||
|
|
||
| <li><p><a>Scroll into view</a> <var>node</var> with |
There was a problem hiding this comment.
No you'd need to specifically say to asynchronously wait for that promise to resolve.
9aa78e9 to
c8c95df
Compare
This PR adds
scrollIntoViewto the general actions.The action should also be able to scroll text nodes (which can be passed in from WebDriver BiDi) and elements with
display: contentsinto view. To this end, the "scroll into view" steps are updated to create aRangeobject for such nodes and call the "Scroll target into view" steps in the CSSOM View spec (which supportRanges) directly.Note that this is a breaking change for interaction commands that implicitly scroll an element into view: previously, the implicit attempt to scroll an element with
display: contentsinto view would do nothing but now it will be scrolled into view.Fixes #1005.
This change is
Preview | Diff