[whatwg] pagehide vs pagevis
Boris Zbarsky
bzbarsky at MIT.EDU
Thu May 30 10:31:34 PDT 2013
On 5/30/13 1:04 PM, Brady Eidson wrote:
> 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)
I believe this is also true in Gecko.
> 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.
It depends on what you mean by "do" and "after". Pages expect certain
network requests to outlive the unload event, for example, for various
phoning-home stuff and break horribly if you disable that (we tried, and
found it to not be web-compatible).
> 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.
This again depends on what "do" means, but ok.
> Would it have made sense for page-vis to put the visibilitychanged event
> *after* unload? I don’t think so.
I think we agree on that.
> 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.
Here's a question. What should the visibilityState be while pagehide is
firing? Should it be "visible" or "hidden", if the page is in a
foreground tab?
It sounds like you're arguing it should be "hidden", right?
> 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”.
Even if it's not going into the page cache?
It's pretty simple, at least in Gecko, to have a page which gets
"pagehide with persisted set to true" and then "unload", if the pagehide
handler does something that prevents the page from being cached after all.
-Boris
More information about the whatwg
mailing list