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

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****
>
> >> >>****
>
> >> >>****
>
> >> >****
>
> >>** **
>
> >>** **
>
> >** **
>
>   ** **
>