- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sun, 02 Oct 2011 18:51:57 -0400
- To: Darin Fisher <darin@chromium.org>
- CC: public-web-perf@w3.org
On 10/1/11 1:15 AM, Darin Fisher wrote: > In Chromium, the visibility state (as WebKit sees it) is modified from > an IPC message (i.e., from a shallow call stack). It is completely > asynchronous to actual tab changes that happen in a separate process. Well, sure, but there could be other visibility-changing things that page script can trigger. And in any case, this doesn't address the concern I actually raised, which was about page-visible visibility state changes, not user-visible visibility changes. The two are pretty loosely correlated, obviously. In any case, here is what Gecko will be implementing if my currently proposed patch lands. I believe the description below is a minimal one that defines the behavior in a way in which this spec should define it; the spec will need it or something like it if different behavior is decided on: 1) visibilitychange events fire synchronously after the visibility state of the document changes. There is no way to observe a document in a changed visibility state without the event having fired (though of course it may not have propagated to your listener yet). 2) The visibility state of a document changes synchronously on page navigations. In particular, it changes to hidden (if not already hidden) synchronously after the firing of the pagehide event and changes to visible as needed synchronously before the firing of the pageshow event. 3) In all other cases, visibility state changes happen directly off the event loop. -Boris
Received on Sunday, 2 October 2011 22:52:25 UTC