1295538 - Actions like press() and click() do not scroll the actionable element into view

Status: RESOLVED WONTFIX

(Remote Protocol :: Marionette, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As given by the webdriver spec actions like click() and press() should bring the element into the viewport before interacting with them. As I can see with some of our unit tests this is not working right now.

It's easy to reproduce on smaller screen resolutions and the following test:

https://dxr.mozilla.org/mozilla-central/source/testing/marionette/harness/marionette/tests/unit/test_key_actions.py?q=file%3Atest_key_actions.py&redirect_type=single#71

The element 'updatediv' is clearly located outside of the screen and as result the press() is not successful. The reason why its outside is that in the setUp() method we click the keyReporter element which is kinda at the end of the test page.

Comment 1

[David Burns :automatedtester]

(In reply to Henrik Skupin (:whimboo) from comment #0)
> As given by the webdriver spec actions like click() and press() should bring
> the element into the viewport before interacting with them. As I can see
> with some of our unit tests this is not working right now.
> 
> It's easy to reproduce on smaller screen resolutions and the following test:
> 
> https://dxr.mozilla.org/mozilla-central/source/testing/marionette/harness/
> marionette/tests/unit/test_key_actions.py?q=file%3Atest_key_actions.
> py&redirect_type=single#71
> 
> The element 'updatediv' is clearly located outside of the screen and as
> result the press() is not successful. The reason why its outside is that in
> the setUp() method we click the keyReporter element which is kinda at the
> end of the test page.

Actions are not supposed to move elements into the view port. We have 2 distinct ways to do interactions for users. We have click() and send_keys() which does move things into the view port and the interactions.

Press and the rest of the "advanced interactions" assume that the user has done the right set of actions to place the element in the view port. 

If the test is out of the view port now we should update the test to make sure it is in the right place.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

David, so it means there is no member of Actions which actually can move an element to the viewport? It would mean that whatever an action change is doing, which involves scrolling, you might have to separate out remaining actions because you have to bring a wanted element back into the view. Is that really what we want? I feel it makes actions less comfortable.

Comment 3

[David Burns :automatedtester]

Yes, this is what we want. Since you want to be doing hovers and the like with actions we have to limit it to the viewport.

Comment 4

[James Graham [:jgraham]]

FWIW I made the same argument at the last F2F meeting for the spec, but there didn't seem to be much appetite for extending the API before it's nailed down. However I am making sure that there is a clear place to implement a scroll action in the future.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to James Graham [:jgraham] from comment #4)
> FWIW I made the same argument at the last F2F meeting for the spec, but
> there didn't seem to be much appetite for extending the API before it's
> nailed down. However I am making sure that there is a clear place to
> implement a scroll action in the future.

So there is https://github.com/w3c/webdriver/issues/1005 now which takes care of implicit scrolling also for actions. I'm going to reopen this issue on behalf of that.

Comment 6

[David Burns :automatedtester]

The issue linked to in comment 5 is to add a new primitive, not do implicit scrolling. Closing this issue as not to conflate the matter and we can raise a new issue when that lands in the spec.