1477973 - Intermittent /webdriver/tests/element_click/interactability.py | test_element_not_visible_overflow_hidden - KeyError: 'element not visible'

Status: RESOLVED INCOMPLETE

(Remote Protocol :: Marionette, defect, P5)

Description

[Treeherder Bug Filer]

Filed by: hskupin [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=182795029&repo=try

https://queue.taskcluster.net/v1/task/d5yCdX-lQsKXh6CTdyy7hw/runs/0/artifacts/public/logs/live_backing.log

Bug 1468146 marked this test as expected fail. It needs to be investigated and fixed.

Comment 1

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

I checked wpt.fyi and this failure is reported as:

https://wpt.fyi/results/webdriver/tests/element_click/interactability.py?labels=experimental

> Failure message: assert 200 == 400 

I see the same failure locally. It means the click command succeeds and doesn't fail. When checking the code the only time when a not interactable error is thrown is when the `isInView` check fails for the element's container after trying to scroll it into view. The container here is the `div`, and it is always visible. 

Here an example: https://codepen.io/anon/pen/RBZqey

What's actually not directly accessible via a click is the input field. But nothing in the spec mentions something for a scroll attempt for the element. Such an attempt would bring the input into view.

I'm unsure if the test as provided is valid or not, or if that is just a bug on our side because we don't make use of the actions API yet.

Andreas, mind having another look at this? Thanks

Comment 2

[Andreas Tolfsen ❲:ato❳]

I looked at the test HTML (put it up on
https://sny.no/e/element_not_visible_overflow_hidden.html) and the
<input> can clearly not be reached by clicking as it is not possible
to scroll the <div>.  However, I note that calling scrollIntoView()
on the <input> brings it into view, which means that by the
specification’s definition, this is a valid test.

I think the intention of WebDriver is for this not to be valid, but
I don’t think there are any primitives that let us get the behaviour
we want here.

Comment 3

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

Ok, so I had another look and here is the real problem...

The input doesn't have a container element as by the definition of the spec because it's not any kind of option or option group. As such the element is the container itself. Which means that step 4 of the "Element Click" command will scroll the input into view:

> 4. Scroll into view the element’s container. 

I don't know why we actually require a `scrollIntoView` here, and maybe it should not be done if the element is the container itself? On the other side Firefox and also Chrome allow to run `scrollIntoView` on the input, and bring it into view.

(In reply to Andreas Tolfsen 「:ato」 from comment #2)
> <input> can clearly not be reached by clicking as it is not possible
> to scroll the <div>.  However, I note that calling scrollIntoView()
> on the <input> brings it into view, which means that by the
> specification’s definition, this is a valid test.

I have to disagree here given that we explicitly say that the container and in this case the element has to be scrolled into view (see above). If `scrollIntoView`  should not bring the element into view because of no scrollbars visible, should we call this a bug in Firefox and Chrome?

Comment 4

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup

Comment 5

[BMO Automation]

Moving bug to Remote Protocol::Marionette component per bug 1815831.