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
