Add steps to destroy documents that are ineligible for receiving message when posting message through broadcast channel

[lozy219]

As discussed in #7253, we should clearly spec that when posting message through broadcast channel, if the destination is not eligible for messaging, the associated document should be made unsalvageable. This PR add some more steps to perform this in the 9.5 Broadcasting to other browsing contexts section.

• At least two implementers are interested (and none opposed):
  • Gecko: How should BroadcastChannel and BFCache interact? #7253 (comment)
  • Chromium: How should BroadcastChannel and BFCache interact? #7253 (comment)
• Tests are written and can be reviewed and commented upon at:
  • https://github.com/web-platform-tests/wpt/tree/master/html/browsers/browsing-the-web/back-forward-cache/broadcastchannel
• Implementation bugs are filed:
  • Chromium: https://crbug.com/1420862

cc @fergald @rakina @domenic @annevk @smaug---- @asutherland please help to take a look 🙇

---

/web-messaging.html ( diff )

[fergald]

@domenic could you take a look at this please and advise on how to land it?

[rakina]

I think it might be worth adding a note clarifying that it is OK to trigger "destroy a document" here because the non-fully active document is either detached or is a BFCached document, which shouldn't receive BroadcastChannel messages and can't be restored after missing this message (maybe also link to https://w3ctag.github.io/bfcache-guide/#gate-fully-active)

[domenic]

@domenic could you take a look at this please and advise on how to land it?

Will do, but it will likely take a few days as my review backlog is quite large at the moment.

[annevk]

I discussed this with some colleagues and we're not really okay with destroying the cache for this case. We currently deliver the messages, but we are open to not delivering them, if that would be better. I suspect that really depends on how BroadcastChannel is used so it's probably not possible to pick something that works well everywhere. Though perhaps we could pick a default and let websites configure it in the constructor.

Edit: as per discussion below WebKit does not deliver the messages.

[fergald]

@annevk From my testing (see below) Mozilla and WebKit (desktop) both drop these if the receiver is in BFCache. Do you have a demontration page where they are queued and delivered?

• BroadcastChannel
• Chrome destroys (actually will not allow the page to enter BFCache but we want to relax this)
• FF/WebKit drops

My reading of the spec right now is that these should be dropped because they are only delivered to active documents. A big concern is that BroadcastChannel is used to log out all tabs when one tab logs out. Dropping these will result in logged-in state being restored from BFCache, which is a serious privacy problem

In general, an API that is reliable until BFCacheing occurs will lead to hard to reproduce bugs.

We're fine with queuing but it would be hard to spec limits on queue size. Leaving that implementation dependent is an option. @asutherland how do you feel about that?

If we queue them, I think the timing is a bit ambiguous. Should they run as soon as the document is active again, i.e. before visibilitychange and pageshow events? That's my fairly naive reading of the spec.

[cdumez]

WebKit doesn't drop b/f cache entries based on BroadcastChannel (or any other Web APIs for that matter). We also do not prevent entering the b/f cache based on BroadcastChannel.

B/f cache entries are very valuable and I personally do not think it is a good idea to discard its entries based on something like BroadcastChannel messages being broadcasted.

[asutherland]

Re: @fergald

We're fine with queuing but it would be #7253 (comment) limits on queue size. Leaving that implementation dependent is an option. @asutherland how do you feel about that?

I think we're eventually going to need to spec the size of structured serialization and storage actions, so I don't think we should view that as insurmountable (but I'm also unable to do the spec work at this time, so I won't presume we have that for this discussion).

A compromise if we are going to queue/buffer things is to set a minimum number of messages that will be buffered, like 3. @cdumez would webkit be interested in supporting buffering on a per-BroadcastChannel basis? (That is, each BroadcastChannel would have its own buffer as opposed to having a shared buffer across all BroadcastChannels associated with a global.) Buffering per-channel allows a page to partition the messages they really want reliable-ish transport for to happen on a rarely used channel, like for "log out" versus "spammy heartbeats".

The upper bound could be implementation dependent, which also makes sense because browsers are going to have implementation-dependent heuristics and underlying implementation costs that determine when a bfached thing is no longer worth its cost.

If we queue them, I think the timing is a bit ambiguous. Should they run as soon as the document is active again, i.e. before visibilitychange and pageshow events? That's my fairly naive reading of the spec.

It seems desirable that a page can unambiguously know if it's seeing buffered messages from BroadcastChannel (or other APIs; ex: some discussion re sessionStorage noting that storage APIs have it easier since they have a canonical backing store). It seems like there are some options for this:

• We add a flag to Events or their bufferable sub-classes that explicitly indicates if they're coming from buffer playback or not. It might be useful to note if the buffer overflowed or not, as one could imagine very complex pages could have a fast path and a slow path that varies on whether there was an overflow.
• We book-end the buffered events so that we schedule the "pageshow" event task, then all of the buffered tasks, then an "all-done-with-buffered-tasks" event task or a promise that we added to "pageshow" that resolves once all the tasks have been dispatched. This has the advantage of letting page logic defer actions until it knows it is caught up to realtime which seems important. I expect in the absence of this, pages may just use setTimeout(0) which probably would work but limits implementation flexibility in the future. (Although I'm not sure of a situation where it would be desirable to let a freshly created timer interleave with the buffered event playback).

[petervanderbeken]

* FF/WebKit drops

Firefox doesn't drop messages, it removes the page from the BFCache if a message is sent to the open BroadcastChannel while in the BFCache.

From what I can tell by testing, WebKit keeps the page in the BFCache but drops the messages sent to the open BroadcastChannel while in the BFCache. @annevk, could you confirm that that's actually WebKit's behaviour? That seems quite weird as a behaviour to me. I think it makes more sense to either remove the page from the BFCache, or to queue the messages. We chose the first one because queueing is definitely more complicated (need to find a sensible limit, …).

[fergald]

Clarifications. When I said "drops" I meant drops the message. So the current state is

• Chrome: no bfcache with BC
• Mozilla: evicts if message is received while in BFCache
• WebKit: drops message

I thought I saw Mozilla behaving the same as WebKit but I cannot reproduce it.

To make life a little easier, I have created a WPT that sends a message to a page in BFCache. It is NOTRUN on Chrome and Mozilla (as expected). I don't have a way to test it on WebKit but I expect it will FAIL.

[fergald]

Can we agree on something before discussing details?

If we restore a page from BFCache it must either

• receive all BC messages or
• have opted-in to dropping messages and can find out when that happened

@cdumez @annevk That is not WebKit's current behaviour, so I would particularly like your response on this.

@petervanderbeken I think you already agree but an explicit response would be helpful.

@asutherland this may be slightly different to your position because it requires an explicit opt-in. This doesn't prevent queuing by default however it means that if the queue overflows, we evict, unless the page explicitly told us that it's OK to drop.

[cdumez]

Can we agree on something before discussing details?

If we restore a page from BFCache it must either

• receive all BC messages or
• have opted-in to dropping messages and can find out when that happened

@cdumez @annevk That is not WebKit's current behaviour, so I would particularly like your response on this.

I am not opposed to: receive all BC messages when restoring a page from the b/f cache (probably up to a certain limit)
I thought this was what we implemented but it wouldn't surprise me if we were dropping messages instead.

Either way, we haven't noticed yet any breakage from our current behavior.

[petervanderbeken]

@petervanderbeken I think you already agree but an explicit response would be helpful.

I discussed it a bit with @smaug----, we still prefer no queueing. Queueing is complicated to spec and implement, ideally you'd then want to specify the limits (taking into account message sizes too). We already have compat issues around limits of just the length of the session history itself for example.

So our position would be: no queueing, evict on message with an opt-in for dropping messages instead.

[fergald]

@petervanderbeken Do we need to spec the details of queueing?

I think you and I agree there should be only 2 outcomes:

• document is restored from BFCache without missing messages
• document is reloaded

To achieve that, we can just say that the messages are queued and delivered if the document becomes active again. If a browser wants to evict with no queueing they are in spec because the document never becomes active again.

[fergald]

Pinging this. Does anyone object to speccing the following?

• documents with an open BroadcastChannel can go into BFCace
• documents reactivated from BFCache should receive all the messages that would have arrived
• (doesn't really need to be said but for clarity here) browsers are free to destroy the document and evict the BFCache entry if they want to e.g. if the queue of messages gets too big

[petervanderbeken]

We're ok with that proposal. We will probably keep our current behaviour at first, which is essentially a message queue length of 0, but the third bullet point allows for that.

I think the main question is if WebKit is interested in changing their behaviour of dropping messages.

[annevk]

That depends on how often it would mean a cache eviction where currently there is none. We don't really want to regress on that as we haven't seen issues with our current behavior.

[fergald]

@annevk

That depends on how often it would mean a cache eviction where currently there is none. We don't really want to regress on that as we haven't seen issues with our current behavior.

Less than 0.4% of history navigations in Chrome have a BC open. I do not know what fraction of that would receive messages.

I can't find any discussion or documentation of BC being unreliable beyond this thread. Before #7296, the spec seemed to say that messages should always be delivered. I don't think devs are aware that it is not reliable, especially as it is reliable on Firefox and Chrome. Pages using BC as a heartbeat will be fine but sites using BC to send incremental updates are definitely broken by this probably in ways that are very hard to trace back to BC+BFCache.

I also don't know what guidance we could give to sites that want a reliable BC. Rebuilding it from other APIs seems hard. If you don't care about reliability but do care about BFCache, closing your BCs in pagehide is easy.

[domenic]

We discussed this in the triage call (#9308) today. Summary:

• WebKit would be open to a queue with an implementation-defined limit while in bfcache, with implementation-defined behavior when the limit is reached. Others on the call were not excited about the implementation-defined post-limit behavior.
• To reach our standard of "2+ implementers support, no strong implementer objections" on requiring eviction when the limit is reached, @annevk would need to check with the rest of the WebKit team as to whether they would strongly object to evicting on exceeding a limit.
  • What would help here is more-specific numbers, which @fergald could help collect, e.g.: what percent of back navs have a BC channel open and receive 1+ messages, 2+ messages, N+ messages, etc. (Or maybe in KiB...)
  • I pointed out that if WebKit sets a limit on the same order of magnitude as "a bfcached web page", it's very unlikely that limit will ever be reached.
• There was some discussion of how this is similar to, or not similar to, storage events. It seems like previously the decision was to not fire any storage events for bfcached pages: Session storage and changing browsing contexts storage#119 (comment) although this was never reflected into the spec. @annevk would be comfortable with dropping all BroadcastChannel messages for bfcached pages in this same manner, but others on the call were not excited about making BroadcastChannel a lossy communications channel.
• In general @annevk was skeptical that sites using BroadcastChannel would correctly respond to queued-and-replayed messages after being taken out of bfcache. Examples of such sites, which would break their functionality with dropped messages but work correctly with replayed messages (especially 2+ replayed messages) would be helpful.

[lozy219]

Hi @annevk , from #8972 (comment) , it looks like we have reached an agreement that mentioning the queueing behavior with a implementation defined capacity is acceptable. We have made some updates ub this pull request, could you help to take a look and confirm if there is any objection from WebKit side?

Also does @fergald 's examples in #8972 (comment) resolved your concern about if sites are able to handle dropped messages? Do you need us to collect any more data to support the proposal?

Thanks.

[annevk]

I feel like there's still no significant data either way that WebKit's existing behavior is problematic. And while we're open to adjusting it in terms of attempting to replay messages, we'd probably still err on the side of wanting to revive a document over replaying its messages. When forced to make a choice between those that is.

[fergald]

Getting back to this as we have someone working on it again.

I feel like there's still no significant data either way that WebKit's existing behavior is problematic. And while we're open to adjusting it in terms of attempting to replay messages, we'd probably still err on the side of wanting to revive a document over replaying its messages. When forced to make a choice between those that is.

I've linked to code that definitely breaks, the firebase code will leave a page in the logged-in state when it should be logged out. Nobody has ever debugged this hard-to-repro problem to the point of filing a bug against Safari but the problem is still there.

If we adopt this behaviour then we need to document that BroadcastChannel is not a reliable communication channel.

I am curious what else Safari does. Does it drop or deliver storage events that occur while in BFCache?

[rakina]

LGTM but it looks like the generated HTML & diff isn't updated yet. Not quite sure how to trigger it, maybe try rebasing and pushing again?

[lozy219]

I modified the description and the links has been updated by the bot.

[domenic]

I was asked to review this but I'm unclear if it reflects (my understanding of) the current cross-browser consensus.

The spec PR evicts immediately on any messages being delivered to a bfcached page.

I guess we can assume this is Chromium's desired behavior?

For Gecko, #8972 (comment) says

So our position would be: no queueing, evict on message with an opt-in for dropping messages instead.

I don't see any opt-in for dropping messages in this PR, but, maybe the idea is to add that later?

But then the discussion moved to @fergald's proposal at #8972 (comment), reiterated by me in #8972 (comment), which includes an implementation-defined queue size limit. And @lozy219 says in #8972 (comment) that he seems to be working on an implementaiton-defined capacity.

I don't see any such capacity limit in this PR. Instead I see what is effectively a capacity limit of 0.

Maybe Gecko and Chromium both agree to a capacity limit of 0? If so I'd like to get Gecko to reaffirm that explicitly. @petervanderbeken @smaug----

With regards to WebKit's position, my read is that their behavior (silently dropping messages while in bfcache) is not spec-conformant either before or after this change. Before this change, the spec says to queue all messages or (implicitly) evict; after this change the spec says to explicitly evict.

So, I think it would be reasonable to merge this if Gecko + Chromium are in favor of it, and WebKit can continue to advocate for a different behavior if they would like the spec to match their implementation where BroadcastChannel becomes unreliable. (Ideally by addressing the data @fergald gathered.)

[domenic]

With regards to WebKit's position, my read is that their behavior (silently dropping messages while in bfcache) is not spec-conformant either before or after this change. Before this change, the spec says to queue all messages or (implicitly) evict; after this change the spec says to explicitly evict.

So, I think it would be reasonable to merge this if Gecko + Chromium are in favor of it, and WebKit can continue to advocate for a different behavior if they would like the spec to match their implementation where BroadcastChannel becomes unreliable. (Ideally by addressing the data @fergald gathered.)

Sorry, this is wrong. I missed a line in the diff. WebKit's behavior matches the current spec, which says to drop the messages and makes BroadcastChannel unreliable.

So, if Gecko also prefers the evict-with-0-buffer behavior, then we have a more clear conflict of Chromium + Gecko preferring one behavior, and the existing spec + WebKit preferring another.

In that case, I don't think it's reasonable to merge this without getting clearer signals from WebKit, per the considerations in #8972 (comment).

[fergald]

For the record, we did not try to measure what would happen if we queued. Implementing the non-queueing version was easy and results in a negligible amount of blocking. We do not plan to do any further work to measure what level of blocking would occur if we queued one message. We could re-propose the queuing version of the spec and state that our queue has a length of zero but if no implementor has an appetite for any value greater than zero, it doesn't make sense.