[whatwg] pagehide vs pagevis

While looking at page visibility, we noticed a couple of problems.

***First***

The “unload a document” steps apparently don’t allow for the pagehide event to have “persisted” set to false.  Step 5 states:
"Fire a trusted event with the name pagehide at the Window object of the Document, but with its target set to the Document object (and the currentTarget set to the Window object), using the PageTransitionEvent interface, with the persisted attribute initialized to true.”

There is no affordance in any steps for the pagehide event to have persisted set to “false”.

In the original design of these events and in WebKit’s implementation, pagehide with persisted “true” means the page is being suspended into the page cache, and it might be restored later.  In these cases, the page does not receive a traditional unload event, as it’s being suspended, not unloaded.

pagehide with persisted “false” means the page is is being traditionally torn down.

The spec’s description of PageTransitionEvent.persisted says "Returns false if the page is newly being loaded (and the load event will fire). Otherwise, returns true.”

That text is geared towards pageshow and completely neglects pagehide.

WebKit has been behaving this way for years and will not change.

***Second***

The “pagehide" and “pageshow" events were originally intended to be drop-in replacements for “load” and “unload”, just with more information to support page caching features.

For the “unload a document” steps, multiple implementors historically had the behavior of “fire pagehide, fire unload, and now no more events will be fired.”  That behavior was supported by the spec.

Additionally, multiple groups had evangelized that pagehide was literally a drop-in replacement for unload: “If you use pagehide instead of unload, the behavior will be exactly the same”

—

Unfortunately the spec has now broken this assumption.  The “unload a document” steps now call for firing pagehide, then giving pagevis a swipe at firing a visibilitychanged event, then firing unload.

Using pagehide as a drop-in replacement for unload now no longer works; After you’ve received pagehide you still might receive a visibilitychanged event, whereas you will receive no such event after unload.

In addition to breaking “pagehide as a replacement for unload” this doesn’t make sense to me on its own.  If a page receives “pagehide” with persisted set to true, it correctly assumes that it might be revived at a later date with a pageshow event.  These pages do not expect any event dispatch between the pagehide and the pageshow...  yet now it might get such events.

I didn’t closely follow pagevis when originally discussed (I now wish I had), but is there any motivation for this?

Short of a good reason for the current behavior I strongly urge the spec to move the pagevis steps to immediately *before* the dispatch of pagehide.

~Brady

Received on Tuesday, 28 May 2013 18:02:26 UTC