- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 02 Feb 2012 21:49:06 -0500
- To: Jatinder Mann <jmann@microsoft.com>
- CC: "arvind@google.com" <arvind@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On 2/2/12 7:52 PM, Jatinder Mann wrote: > I don't think it makes sense to fire the visibilitychange event after the unload event - the unload event should be the last chance to run code prior to unloading. That's fine. The way I implemented it in Gecko is that visibilitychange fires from the same task as pagehide and unload, after pagehide and before unload. I buy the argument about firing it before unload, but would prefer to fire after pagehide. > We can consider firing the visibilitychange event synchronously before the unload from the same task. That's the proposal, yes. > If we are to fire the visibilitychange event prior to unloading, we may want to inform developers that this particular visibilitychange is occurring during the unload, so they can make a performance decision of whether or not to run code at that point. I recommend that when the visiblitychange event is fired when unloading, we also synchronously change the hidden attribute of Document to "unloading". What if the document is not in fact "unloading" but instead going into a history cache? I'd like to understand the use cases here before adding more complexity, honestly. > As for pagehide and pageshow, if you're relying on visibilitychange to throttle work, wouldn't you want to fire the visibilitychange event prior to the pagehide/pageshow? For UAs that support traversing to and from session history entries, we would also want to specify the ordering of pagehide/pageshow, visibilitychange and unload. Of course, unload would be the last, so we really need to determine the order of the first two. The reason I want to fire visibilitychange before pageshow and after pagehide is that: 1) The latter preserves the invariant that it actually triggers on visibility state changes: it fires after we're actually hidden. 2) The former preserves the general ordering of visibility changes and page show/hide. During a document load, for example, the document becomes visible (there is no event for this initial visibility change) and then fires pageshow sometime later, right? But I'm not religious about this, honestly. As long as visibilitychange fires either "inside" pageshow/pagehide or "outside" it, but consistently, I can live with it. -Boris
Received on Friday, 3 February 2012 02:49:35 UTC