- From: Brady Eidson <beidson@apple.com>
- Date: Thu, 30 May 2013 10:04:11 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: whatwg@lists.whatwg.org
On May 29, 2013, at 6:36 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Let's actually back up a second. > > What problem are you really trying to solve by changing the ordering? As I see it, right now the situation is as follows (in implementations, if not in the spec): > > 1) pagehide fires, with a boolean indicating whether at this point the UA plans to place the page in the page cache. Correct. > 2) Whether the page is in fact placed in the page cache depends on actions taken by scripts on the page that fire from the pagehide event (at least in Gecko). Correct. > 3) Even after a page has been placed in the page cache it can be evicted from the page cache for various reasons (again, at least in Gecko). Correct. Of course note that pages that have been placed in the page cache that are evicted have no visibility that the eviction occurred (at least in WebKit) > How does the firing of visibilitychange events after pagehide affect things here in an undesirable way? I can answer this in two buckets. --- Bucket 1 - “Pages not going in to the page cache” Let me ask you this - Are there any (reasonable) pages in the wild that (reasonably) expect to do anything *after* the unload event is fired? I would say no, probably not. If a page listens to pagehide instead of unload, then they are not reasonably expecting to do anything after "pagehide with persisted set to false” is fired. Especially since “pagehide with persisted set to false” was identical to “unload” until this change in the spec. Would it have made sense for page-vis to put the visibilitychanged event *after* unload? I don’t think so. No author would expect that or find it very useful. So I still cannot see how having it after "pagehide with persisted set to false” is the right call. Maybe authors writing to the spec might expect it, but they wouldn’t find it very useful. --- Bucket 2 - “Pages going in to the page cache” The long standing design goals and implementation of our page cache prevents us from delivering these events to a page that was just sent “pagehide with persisted set to true”. So it’s undesirable for two reasons: 1 - We can’t meet the spec. 2 - Authors can’t get the possible benefit that were available to them if the spec was reasonable in sending visibilitychanged before pagehide instead of after. ~Brady > > -Boris
Received on Thursday, 30 May 2013 17:04:43 UTC