- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 30 May 2013 13:24:52 -0400
- 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: <script>alert(document.visibilityState)</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... -Boris
Received on Thursday, 30 May 2013 17:25:23 UTC