This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22653 - Container visibility when children are visible, but parent is hidden
Summary: Container visibility when children are visible, but parent is hidden
Status: RESOLVED FIXED
Alias: None
Product: Browser Test/Tools WG
Classification: Unclassified
Component: WebDriver (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: seva
QA Contact: Browser Testing and Tools WG
URL:
Whiteboard:
Keywords:
: 23309 (view as bug list)
Depends on:
Blocks: 20860
  Show dependency treegraph
 
Reported: 2013-07-12 14:32 UTC by Andreas Tolf Tolfsen
Modified: 2015-10-26 00:53 UTC (History)
3 users (show)

See Also:


Attachments

Description Andreas Tolf Tolfsen 2013-07-12 14:32:02 UTC
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.
Comment 1 David Burns :automatedtester 2014-02-04 00:22:25 UTC
*** Bug 23309 has been marked as a duplicate of this bug. ***
Comment 2 seva 2014-07-07 00:04:38 UTC
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.
Comment 3 seva 2014-07-07 14:42:53 UTC
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.
Comment 4 David Burns :automatedtester 2015-10-26 00:53:45 UTC
this has been corrected in the spec