This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At the last W3C webdriver spec meeting we discussed the scenario where you have an ancestral element hiding it's overflow, and a parent element with two absolutely position child elements. The parent element is not visible to the user, but as a container element for the two visible child elements it can be considered interactable. An example is a container element, such as a menu, located off-viewport with its child elements in-view. From a user perspective the menu is definitely visible, should webdriver also consider the container visible? See the following patch for an example: https://github.com/w3c/web-platform-tests/commit/1c76adbcb5b718bbf8e4045a1598711fca89868d The conclusion we reached at the meeting was it we would differentiate between interactability and visibility. This has not yet been covered in the specification.
*** Bug 23309 has been marked as a duplicate of this bug. ***
I meant to get to this and propose spec, but didn't to date. I don't think I was at the f2f where this was discussed for the first time so might be missing some context. I am not sure I follow why the parent element in the example should just be considered interactable and not also visible (it has visible children, user sees them, that means user "sees" the parent, no?). I still see use for interactability and visibility as distinct properties: some invisible elements can be tab'ed into and then typed into; that would count as an interaction while some other kinds of interaction such as click would not be possible since the element is not visible.
Detecting such parent element (with absolutely positioned visible children but otherwise invisible) as visible might not be feasible in a JavaScript implementation for performance reasons. But it may very well be feasible in a native implementation. And I believe it would make for a better isDisplayed eventually. Proposal: consider two modes/levels for visibility: 1. (what is described now) "compatibility", the current atoms/JavaScript implementation 2. (what it should be ideally) "precise", where elements (and their children combined) actually visible to the user are reported 'displayed'. Doing this opens up ways for improvements to visibility detection. Right now the specification basically says that the perfectly precise isDisplayed is not compliant.
this has been corrected in the spec