- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 20 Apr 2012 01:33:47 -0400
- To: Sreeram Ramachandran <sreeram@google.com>
- CC: public-web-perf@w3.org
On 4/20/12 1:26 AM, Sreeram Ramachandran wrote: > Right, but this is for an iframe. Sorry, I should've been clearer that > I was asking about top level documents. It should work the same exact way for toplevel documents. Certainly does in Gecko. > Your example above works, as does the iframe example earlier in the thread > (navigation-page-visibility.html). However, since iframes are given > the same visibility as the "top level browsing context", their > visibilitystate doesn't change when they are navigated or removed from > the DOM, etc. They do in my Gecko implementation, because the defaultView goes null when navigating away and the spec calls for a visibility change at that point, even for an iframe. Furthermore, once a document is no longer associated with a browsing context (has been unloaded), it's not exactly associated with a toplevel browsing context either, and giving it independent visibility makes sense. > So, it seems to me that iframes don't motivate the case > for firing visibilitychange events during pagehide or unload. In > contrast, a top-level document that is navigated away from does have > its visibilitystate changed, but I haven't been able to find a way to > script it. Just do the same exact thing as my testcase, but use window.open() to get the window, instead of an iframe's contentWindow. And make sure to wait for that window to load. > The defaultView issue remains, but I suppose that can be handled by > being more flexible in the spec (i.e., perhaps change the "MUST" > language to something more relaxed). Not if we actually want interop... -Boris
Received on Friday, 20 April 2012 05:34:18 UTC