Closed Bug 1477973 Opened 2 years ago Closed 2 years ago

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

Categories

(Testing :: geckodriver, defect, P5)

Version 3
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure)

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.
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
Flags: needinfo?(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.
Flags: needinfo?(ato)
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?
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.