-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How should BroadcastChannel and BFCache interact? #7253
Comments
For BroadcastChannel instances associated with detached iframes or closing workers, update the specification to require that calls to postMessage() should be ignored (without throwing an exception). Closes whatwg#7219. Some potential followup in whatwg#7253 for the related bfcache case.
For BroadcastChannel instances associated with detached iframes or closing workers, update the specification to require that calls to postMessage() should be ignored (without throwing an exception). Closes whatwg#7219. Some potential followup in whatwg#7253 for the related bfcache case.
Apparently Firefox's behavior has compat issues with GitHub itself; see https://bugzilla.mozilla.org/show_bug.cgi?id=1772739#c10 . This might be a motivation for different browsers to get on the same page here, to avoid these sorts of compat issues. |
Note, that Github issue seems to be something very recent, they have changed something on their side, I think. |
I don't know what unsalvageable means in this context. It is same as evicting from bfcache? |
"unsalvageable" is the spec language for eviction. An inactive document that is still salvageable can still be navigated to. BroadcastChannel prevents < 0.1% of BFCache usage, so it's low priority for chrome to improve. So, the question is whether we should spec that receiving a broadcast message evicts. What is the bad thing that would happen some impl decided to just queue the messages and deliver them on restore? |
This isn't accurate. Salvageability is used for determining whether a document can stay in bfache at unload time. Eviction consists of nulling out a session history entry's document at some later time and is unrelated to salvageability. |
Thanks for the correction. I see "Apart from these restrictions, this standard does not specify when user agents should discard an entry's document, versus keeping it cached." This sentence here is odd. I guess we have never specced an eviction case yet but that makes it sound like we won't (as opposed to coincidentally just haven't yet). |
Agreed, we should reword that. Having that defined would also help with whatwg/fs#17 (comment). |
Yeah I don't think anything currently specs eviction that happen after unload steps. In addition to updating the note, I think we should also add a hook to spec eviction that other specs can refer to (that can be called with just the document, so the callers don't need to find the relevant entries that needs to have their document nulled out?) |
So should we just extend the use of salvageable to mean what I thought it meant, i.e. a document can be marked unsalvageable when in BFCache and an unsalveagable document gets it's entries nulled out? |
I think we have two options here:
#1 seems more natural but #2 is closer to what Chrome actually does in implementation. I'm not sure if there are implicit side effects of not evicting the entry until we actually traverse to it, but #1 seems preferable to me. I can send a PR if there are no problems with that. |
I think for certain cases we need 2, right? E.g., some other document wants to obtain a lock so we'll just pretend that the bfcache entry with a lock never existed. |
I would prefer (2). "Salvageable" is about the act of "salvaging", which I think is best interpreted as "keeping the document even when you're throwing away a bunch of other stuff". |
In my mind the salvaging happened when the traversal occurred, i.e. salvage = restore. I guess I got that from https://html.spec.whatwg.org/multipage/browsing-the-web.html#the-pagetransitionevent-interface
but having read the steps more closely, I agree that a separate nulling operation makes sense. |
So to come back to the original question. What should the spec say about a page with an open BCs?
I think we all agree that it's not 1. but is it necessary to spec that it's 2.? If some browser wanted to implement 3. what would be the correctness or privacy problem? Obviously implementation-wise you wouldn't want to queue lots but 1 or 2 seems harmless. Spec-wise, it looks like 3. would just require removing the "is fully active" qualification from eligible for messaging. |
The advantage of specifying 2 (evict on receipt of any message) for now:
|
Yeah, I don't think we should or could standardize queue sizes (at most we could standardize max queue sizes since browsers are free to evict whenever they want for no user-visible reason). I also expect that the incremental benefit of queuing some message is probably much lower than that of allowing pages into the cache until a message is sent (I assume that the frequent heartbeats use case is rare). We will know this from our telemetry in Chrome once we get around to allowing this but currently all BC accounts for < 1% of all non-cached history navigations. So then if we were to spec that messages cause eviction, it would simply be because we think it's better to have predictable behaviour than get that last tiny fraction of caching. That's fine with me, I just want to be explicit. |
Forking off from #7252. I don't think this is urgently needed, just trying to gather all the info in one place.
The question for BFCache is whether a message being sent to a BFCached frame should cause the frame/page to become unsalvageable. What's specced right now is that the message should not be delivered.. We can
1 leave it as is
2 spec that it makes it unsalvageable
3 spec that it may be queued and delivered if the page is restored (size of queue is up to implementation, marking as unsalvageable is OK at any point)
4 spec that it's dropped
5 note that it's currently unresolved
1 and 3 are somewhat equivalent in that if we don't disallow it, a browser is not out of spec for doing it (although it's following an unspecced queuing algorithm).
2 is Firefox's behaviour.
3 is nobody's behaviour but does not seem incompatible with current spec and doesn't seem raise security or privacy issues. It could be a surprise to some pages to receive events late or in quick succession as the queue is flushed (arguably no worse than if a page ran a very long task).
4 is nobody's behaviour either but dropping messages violates expectations of reliability
I would just like to avoid speccing or testing that we cannot queue and deliver later, unless someone has a strong reason for it being wrong.
@asutherland @wanderview @rubberyuzu @cdumez @domenic
The text was updated successfully, but these errors were encountered: