Re: making page visibility a property of document instead of top level browsing context

Walter and I have been thinking about how to expand the normative
definition of visibility. We believe it's possible to draw some parallels
between the two specs, and find a good pragmatic balance between
implementability and usefulness by breaking visibility into categories of
reasons to return “hidden”:

1) CSS styling: Whether the Document or one of its parent elements is
styled so that it is hidden, such as with "display:none",
"visibility:hidden", or "opacity:0".

This applies to both the current spec and the draft spec. Today, for
example, applying “display: none” to the top-level document element causes
the visibilityState to return hidden.

2) Backgrounding: Whether the user agent is minimized or the tab is in the
background.

This applies to both specs, but current implementations of the spec do not
fully comply. Walter gave some examples of some inconsistencies up-thread.

3) Intersecting viewports: Whether the Document intersects with the User
Agent’s viewport or the screen.

The first part is less applicable to the current spec, since focused
top-level Documents always intersect with the viewport. The second part is
not currently implemented (despite the spec’s language) and may not be
worth caring about.

4) Covering: Whether the Document is covered by other entities such as HTML
elements, OS windows, or screensavers.

It may be reasonable to expect detection of HTML elements covering the
otherwise-viewable portion of a Document, but it may be too difficult to
detect other application windows covering it.

5) Opacity: Whether any covering elements are partially transparent.

We think trying to cover opacity (and images, canvases, etc.) gets
complicated for almost no gain. We think it'd be realistic to ignore this
class of cases and assume all covering elements are opaque.

These are some of our thoughts. Let us know what you think.

-Rudy

> You're right that the Page Visibility L1 spec does tie the definition of
> visibility to the top level document. It's tied to that document being
> "visible on at least one screen", without elaboration, as far as I can
tell..
>
> For sure, above-the-fold and CSS concerns become more prominent in the L2
> draft, but to some extent those concerns already exist in L1 and are
> sometimes ignored, probably due to technical limitations. All the
following
> currently count as "visible" in all browsers I tested: the browser
> application is obscured by other applications; the browser application is
> manually moved off screen; the browser application resides in an inactive
> virtual desktop; in OS X, the browser application is Hidden (the
> window-manager equivalent of "display: none"). In addition, I found that
> while Chrome, Firefox, and IE all report "hidden" when minimized in
> Windows, Chrome reports "visible" when minimized in OS X, and both Chrome
> and Firefox report "visible" when minimized in Ubuntu with Unity.
>
> Though I find these behaviors inconsistent with the spec as written, I
> still find the spec implementations very useful. That said, clarifying the
> draft spec is probably a good idea. I don't think following the current
> windowing behaviors is the right path for iframes, and fortunately,
iframes
> aren't subject to the same technical limitations. We should take advantage
> of that.
>
> -Walter
>
>
> On Tue, Oct 22, 2013 at 4:39 PM, Jatinder Mann <jmann@microsoft.com>
wrote:
>
> >  > I’m not sure why the current spec’s normative definition suffices but
> > the draft’s does not. Why is that?****
> >
> > ** **
> >
> > The Page Visibility L1 spec ties the definition of visibility to the top
> > level document, which is simpler as the visibility of the top level
> > document matches that of the tab it resides in. With the L2 spec, we are
> > tying the definition of visibility to the document itself. E.g., an
iframe
> > can be visible or not depending on whether it is above or below the
fold,
> > as well as whether the tab it resides in is foreground. I do think we
will
> > need to provide more details. Maybe something like below:****
> >
> > ** **
> >
> > "On getting, the visibilityState attribute MUST return the DOMString
> > visible if the Document is at least partially visible at on at least one
> > screen. If the bounding box of the Document is inside the User Agent’s
> > interpretation of the top level Document’s viewport or the Document has
> > been styled such that its display property is not set to none, on
getting
> > the visibilityState attribute MUST return “visible”.****
> >
> > ** **
> >
> > I rather we keep some text around “User Agent’s interpretation of the
top
> > level Document’s viewport”, as most browsers render more than just the
> > content in the viewport to support smooth panning/scrolling. ****
> >
> > ** **
> >
> > > But it may be worth noting that, for example, in minimized windows the
> > behavior of visibilityState differs
> > > across browser vendors and OSes (with the caveat that the attribute is
> > still vendor-prefixed).****
> >
> > ** **
> >
> > At least with Page Visibility L1, a minimized browser window should
return
> > the visibilityState of “hidden”. Do you have examples of where this
isn’t
> > the case? I know that a browser window that is fully obscured by other
> > windows still returns as visible, as that is case is typically harder to
> > determine.****
> >
> > ** **
> >
> > *From:* Walter Mostowy [mailto:mostowy@google.com]
> > *Sent:* Tuesday, October 22, 2013 2:46 PM
> > *To:* James Robinson
> > *Cc:* Arvind Jain; Jatinder Mann; Jonas Sicking; Ojan Vafai;
> > public-web-perf
> >
> > *Subject:* Re: making page visibility a property of document instead of
> > top level browsing context****
> >
> > ** **
> >
> > I have a question -- I apologize for my ignorance. The current normative
> > definition in the current spec appears to be this:
> >
> > "On getting, the visibilityState attribute MUST return the DOMString
> > visible if the Document contained by the top level browsing context is
at
> > least partially visible at on at least one screen."
> >
> > The counterpart in the draft is this:
> >
> > "On getting, the visibilityState attribute MUST return the DOMString
> > visible if the Document is at least partially visible at on at least one
> > screen."
> >
> > I’m not sure why the current spec’s normative definition suffices but
the
> > draft’s does not. Why is that?
> >
> > There are additional CSS concerns, to be sure. But it may be worth
noting
> > that, for example, in minimized windows the behavior of visibilityState
> > differs across browser vendors and OSes (with the caveat that the
attribute
> > is still vendor-prefixed). The current spec seems to be useful in spite
of
> > the incompleteness -- I know it has been useful to me.
> >
> > -Walter****
> >
> > ** **
> >
> >  ** **
> >
> > ** **
> >
> > There's no normative definition of what "visible" means here for a****
> >
> > document.  I think you have to be precise here in order to make this
useful****
> >
> > for web developers.  Notes aren't normative.****
> >
> > ** **
> >
> > Nothing on the web platform today exposes the notion of what part of
a****
> >
> > document is 'visible', so I think you have quite a bit of writing to
do.****
> >
> > ** **
> >
> > - James****
> >
> > ** **
> >
> > ** **
> >
> > On Thu, Oct 10, 2013 at 4:26 PM, Arvind Jain <arvind@google.com <
arvind@google.com?Subject=Re%3A%20making%20page%20visibility%20a%20property%20of%20document%20instead%20of%20top%20%20level%20browsing%20context&In-Reply-To=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E&References=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E>>
wrote:****
> >
> > ** **
> >
> > > I've put a draft here:****
> >
> > >** **
> >
> > >
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility2/Overview.html****
> >
> > >** **
> >
> > > The main change from previous version of PageVisibility is making****
> >
> > > visibility a property of the document (as opposed to top level
browsing****
> >
> > > context) as we proposed and agreed upon no this thread.****
> >
> > >** **
> >
> > > Please let me know if you have any feedback. One question I have
is****
> >
> > > whether we define more values for "visibilityState" to cover
different****
> >
> > > cases like the following:****
> >
> > > 1) Browser window minimized.****
> >
> > > 2) Background tab.****
> >
> > > 3) IFrame outside of viewport.****
> >
> > > 4) One of document's ancestor is set to display:none****
> >
> > >** **
> >
> > > Arvind****
> >
> > >** **
> >
> > >** **
> >
> > > On Tue, Aug 27, 2013 at 3:25 PM, Jatinder Mann <jmann@microsoft.com <
jmann@microsoft.com?Subject=Re%3A%20making%20page%20visibility%20a%20property%20of%20document%20instead%20of%20top%20%20level%20browsing%20context&In-Reply-To=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E&References=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E
>>wrote:****
> >
> > >** **
> >
> > >> In the current Page Visibility spec, querying document.hidden from
an****
> >
> > >> iframe returns the correct value, true, when the browser is
minimized or****
> >
> > >> the tab is in the background. The property incorrectly returns false
when****
> >
> > >> the top level document is visible, but the iframe is below the fold.
I****
> >
> > >> don't see any compatibility issues of improving the fidelity of
information****
> >
> > >> provided by this property in the iframe context in a Page Visibility
L2****
> >
> > >> spec.****
> >
> > >>** **
> >
> > >> -----Original Message-----****
> >
> > >> From: Jonas Sicking [mailto:jonas@sicking.cc <jonas@sicking.cc
?Subject=Re%3A%20making%20page%20visibility%20a%20property%20of%20document%20instead%20of%20top%20%20level%20browsing%20context&In-Reply-To=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%
40mail.gmail.com
%3E&References=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%
40mail.gmail.com%3E>]****
> >
> > >> Sent: Saturday, August 24, 2013 6:13 PM****
> >
> > >> To: Ojan Vafai****
> >
> > >> Cc: Arvind Jain; public-web-perf****
> >
> > >> Subject: Re: making page visibility a property of document instead
of top****
> >
> > >> level browsing context****
> >
> > >>** **
> >
> > >> Agreed. It seems quite possible that this won't break any
existing****
> >
> > >> content.****
> >
> > >>** **
> >
> > >> / Jonas****
> >
> > >>** **
> >
> > >> On Sat, Aug 24, 2013 at 5:55 PM, Ojan Vafai <ojan@chromium.org <
ojan@chromium.org?Subject=Re%3A%20making%20page%20visibility%20a%20property%20of%20document%20instead%20of%20top%20%20level%20browsing%20context&In-Reply-To=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E&References=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E>>
wrote:****
> >
> > >> > Ideally we wouldn't add a new property. So, we should try
shipping****
> >
> > >> > this in the backwards-incompatible way (i.e. changing the
existing****
> >
> > >> > property) and see if we can get away with it.****
> >
> > >> >****
> >
> > >> >****
> >
> > >> > On Sat, Aug 24, 2013 at 5:30 PM, Arvind Jain <arvind@google.com <
arvind@google.com?Subject=Re%3A%20making%20page%20visibility%20a%20property%20of%20document%20instead%20of%20top%20%20level%20browsing%20context&In-Reply-To=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E&References=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E>>
wrote:****
> >
> > >> >>****
> >
> > >> >> Is it ok to just update the spec in a non compatible way i.e. in
the****
> >
> > >> >> new version of the spec, we say visibility is at document
level****
> >
> > >> >> (which would be not backwards compatible). Or do we need to add a
new****
> >
> > >> property?****
> >
> > >> >>****
> >
> > >> >> Arvind****
> >
> > >> >>****
> >
> > >> >>****
> >
> > >> >> On Sat, Aug 24, 2013 at 5:22 PM, Jonas Sicking <jonas@sicking.cc<jonas@sicking.cc
?Subject=Re%3A%20making%20page%20visibility%20a%20property%20of%20document%20instead%20of%20top%20%20level%20browsing%20context&In-Reply-To=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%
40mail.gmail.com
%3E&References=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%
40mail.gmail.com%3E>>****
> >
> > >> wrote:****
> >
> > >> >>>****
> >
> > >> >>> We at mozilla is certainly in support of this. In fact, bz
has****
> >
> > >> >>> strongly argued that this should be the case for a very long
time.****
> >
> > >> >>>****
> >
> > >> >>> / Jonas****
> >
> > >> >>>****
> >
> > >> >>> On Aug 24, 2013 2:11 PM, "Arvind Jain" <arvind@google.com <
arvind@google.com?Subject=Re%3A%20making%20page%20visibility%20a%20property%20of%20document%20instead%20of%20top%20%20level%20browsing%20context&In-Reply-To=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E&References=%3CCAD73mdJ%2BDUBm49YXEZENR-NMJz2qv9mhGFTaBap2CFxUBPvRqQ%40mail.gmail.com%3E>>
wrote:****
> >
> > >> >>>>****
> >
> > >> >>>>****
> >
> > >> >>>> Hi,****
> >
> > >> >>>> I've seen a few requests where developers would like to query
for****
> >
> > >> >>>> visibility of their IFRAME (when the iframe is in third
party****
> >
> > >> context).****
> >
> > >> >>>>****
> >
> > >> >>>> Today, in Page Visibility, we set document.visibilityState
to****
> >
> > >> "hidden"****
> >
> > >> >>>> or "visible", but it is really the visibility of the top
level****
> >
> > >> >>>> browsing context that includes the given document. This
information****
> >
> > >> >>>> is made available to third party IFRAMEs.****
> >
> > >> >>>>****
> >
> > >> >>>> What do folks think of making document.visibilityState the
property****
> >
> > >> >>>> of the document itself instead of the top level browsing
context?****
> >
> > >> >>>> That way you can detect conditions like when the IFRAME is
below****
> >
> > >> >>>> the fold and therefore not visible while the top level
browsing****
> >
> > >> context itself is visible.****
> >
> > >> >>>>****
> >
> > >> >>>> Thanks,****
> >
> > >> >>>> Arvind****
> >
> > >> >>****
> >
> > >> >>****
> >
> > >> >****
> >
> > >>** **
> >
> > >>** **
> >
> > >** **
> >
> >   ** **
> >