Closed Bug 1477973 Opened 2 years ago Closed 2 years ago
_click/interactability .py | test _element _not _visible _overflow _hidden - Key Error: 'element not visible'
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
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.
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?
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.