W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2013

Re: [whatwg] pagehide vs pagevis

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 30 May 2013 13:24:52 -0400
Message-ID: <51A78B64.5040801@mit.edu>
To: Brady Eidson <beidson@apple.com>
Cc: whatwg@lists.whatwg.org
On 5/30/13 12:41 PM, Brady Eidson wrote:
>>> pageshow is a history traversal event, and not a visibility event.  I
>>> don’t see a guarantee in any spec that “pageshow” comes after the
>>> document is actually visible.
>> It comes after it's visible in terms of document.visibilityState, for
>> pages not in background tabs.
> This is true *only* because you and the other people who worked on
> integrating page-vis into HTML decided it was true.

No, this is true because the other option is nonsense.

If I'm loading an HTML page in a foreground tab, and it has this script:


Then the alert had better show "visible" in a sane world, and will 
definitely happen before pageshow fires.

> What I meant was that the pageshow event does *not* inherently mean that
> the page is actually visible

Sure thing.  Neither does a visibility state change.

> Whereas the visibilitychanged event would (presumably?) only
> fire once the pixels are painted on the screen.

Of course not.  The visibility API does not take occlusion of any sort 
into account.  It's trivial to have things that claim to be "visible" 
for purposes of visibility API that have no pixels anywhere on screen.

> Only people without page caches or with a gecko-style page cache could
> ship this.

What makes a page cache "gecko-style"?  I'm still trying to understand 
exactly what prevents you from shipping the currently specified ordering...

Received on Thursday, 30 May 2013 17:25:23 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:59 UTC