Bug 116769 - Page Visibility incorrect for documents in the page cache
Summary: Page Visibility incorrect for documents in the page cache
Status: RESOLVED DUPLICATE of bug 151234
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: 2020-09-25 17:54 PDT (History)
12 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.
Comment 7 sideshowbarker 2020-09-24 22:16:19 PDT
(In reply to Brady Eidson from comment #6)
> On IRC, Hixie agreed in principle that this should be changed in the spec,
> especially if there hasn't been any full implementations yet.

https://freenode.logbot.info/whatwg/20130528#c797054 seems to the record of that discussion.

> I've emailed WHATWG about this.

https://lists.w3.org/Archives/Public/public-whatwg-archive/2013May/thread.html#msg156 seems to be the record of that discussion thread.

I couldn’t find any response from Hixie in the archive for that month — so I kept looking through the archives for the months that followed, and found  https://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0336.html (three months later).

But in looking through the 289 commits Hixie made https://github.com/whatwg/html/commits?author=Hixie&since=2013-05-28&until=2013-09-01 between the time of that end-of-May-2013 e-mail thread at his end-of-August-2013 response, https://github.com/whatwg/html/commit/f96b411 is the only related spec change I found among all those.

Based on comments from comments from Ilya Grigorik elsewhere, I feel that Ilya at least doesn’t agree that spec change entirely solves the problem, and that instead there may still be an implementation problem here that needs resolving.

Therefore, I’m taking the liberty Cc’ing Ilya here — so that he can weigh in and so that we can hopefully reach some resolution on this.
Comment 8 Chris Dumez 2020-09-25 17:54:43 PDT

*** This bug has been marked as a duplicate of bug 151234 ***