- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 12 Dec 2013 15:40:09 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@lists.whatwg.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Wed, Dec 11, 2013 at 4:54 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>> The proposal at [1] does not prevent bfcaching *anytime* that >>> MessagePorts are alive in a page that is navigated away from. We can >>> always bfcache the page if we don't know of any "other sides" having >>> pinned their port. If we later detect that a port is being pinned, we >>> can indicate an error to the pinning side, and throw the bfcached page >>> out of the bfcache at that time. >> >> It might be too late by then, since you might have already navigated back >> to the bfcached page. This is why the IPC has to be synchronous, at the >> latest during the back() navigation. (Not literally synchronous, I guess, >> since otherwise you'd have trouble handling a mirror image scenario where >> both sides were playing this game, but at least it needs to block the >> history traversal back to a document that is bfcached but for which we may >> not yet have received confirmation that the bfcache is clean.) > > No sync IPC needed. When a port is pinned, you send an async message > to the process which contains the page for the "other side". When that > process receives the message you check if the page is currently being > displayed. To add additional clarification here. It's ok if the receiving page has gone into bfcache and come back while the message was in transit. If the user is away from the page short enough that the page is rendered again by the time the message arrives, then the page will be able to respond and no errors need to be signaled. I.e. effectively the responder never disappeared. / Jonas
Received on Thursday, 12 December 2013 23:41:04 UTC