Bug 116769 - Page Visibility incorrect for documents in the page cache
Summary: Page Visibility incorrect for documents in the page cache
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 116645 116770
  Show dependency treegraph
 
Reported: 2013-05-25 15:35 PDT by Simon Fraser (smfr)
Modified: 2019-07-17 04:00 PDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Fraser (smfr) 2013-05-25 15:35:39 PDT
Page Visibility is really about document visibility. We store it on Page, and a Page outlives document navigation. So it's not possible for us to have documents in the page cache have a different visibility to the current page.

Another victim of the poorly defined top-level objects.
Comment 1 Simon Fraser (smfr) 2013-05-25 18:00:35 PDT
More info:
http://www.w3.org/TR/html5/browsers.html#unloading-document-visibility-change-steps and http://www.w3.org/TR/page-visibility/ say page visibility should change after the pageHide event is fired.  document.visibility should transition to hidden, and then a visibilitychange event should be sent.

Similarly on pageShow when coming out of the cache.
Comment 2 Brady Eidson 2013-05-26 18:15:17 PDT
(In reply to comment #1)
> More info:
> http://www.w3.org/TR/html5/browsers.html#unloading-document-visibility-change-steps and http://www.w3.org/TR/page-visibility/ say page visibility should change after the pageHide event is fired.  document.visibility should transition to hidden, and then a visibilitychange event should be sent.

Sending an event *AFTER* pageHide is akin to sending an event *AFTER* unload.  That is *nuts*.

> Similarly on pageShow when coming out of the cache.

No argument here.
Comment 3 Brady Eidson 2013-05-26 18:24:25 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > More info:
> > http://www.w3.org/TR/html5/browsers.html#unloading-document-visibility-change-steps and http://www.w3.org/TR/page-visibility/ say page visibility should change after the pageHide event is fired.  document.visibility should transition to hidden, and then a visibilitychange event should be sent.
> 
> Sending an event *AFTER* pageHide is akin to sending an event *AFTER* unload.  That is *nuts*.

Note - I am not arguing that this is what the spec *says* to do.  Yes, the spec now says to do this.  I'm just saying it is absolutely nuts.

We've been evangelizing to authors that pageHide is the *EXACT* same thing as unload, except with more information and is compatible with page caching features.

Part of the "pageHide is the same as unload" guarantee was that no events will come after them.  e.g. if you opt in to listening to pageHide instead of unload, then that's the last event you need to listen to until pageShow.

Now that the spec says "fire pageHide, then fire visibilityChanged, then fire unload", pageHide is no longer functionally equivalent to unload.  And that blows.
Comment 4 Simon Fraser (smfr) 2013-05-28 09:29:42 PDT
> We've been evangelizing to authors that pageHide is the *EXACT* same thing as unload

So we were wrong.
Comment 5 Alexey Proskuryakov 2013-05-28 09:39:54 PDT
> So we were wrong.

Why? The page visibility spec is much newer than the well established design for pageshow/pagehide.

I agree with Brady that the Page Visibility spec is wrong, and should be fixed or ignored.
Comment 6 Brady Eidson 2013-05-28 11:32:55 PDT
On IRC, Hixie agreed in principle that this should be changed in the spec, especially if there hasn't been any full implementations yet.

I've emailed WHATWG about this.