[whatwg] onclose events for MessagePort

[Jonas Sicking]

On Wed, Dec 11, 2013 at 4:54 PM, Jonas Sicking <jonas at 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