I created an issue specifically for the BroadcastChannel discussion: https://github.com/WICG/nav-speculation/issues/141
We'd love to hear if there are other issues with restrictions (or other) that need addressing! Browse/open at https://github.com/WICG/nav-speculation/issues On Monday, February 14, 2022 at 6:38:40 PM UTC+2 [email protected] wrote: > On Mon, Feb 14, 2022 at 11:33 AM Noam Rosenthal <[email protected]> > wrote: > >> >> >> On Saturday, February 12, 2022 at 7:11:29 AM UTC+2 [email protected] >> wrote: >> >>> I agree with Domenic that it's great to see this kind of feature, that >>> was traditionally unspecified, getting some clearer developer visibility >>> and a spec. While there may still be missing pieces, this seems like a good >>> start. I'm looking forward to further spec discussions that would hopefully >>> lead to convergence and better interop. >>> >>> On Fri, Feb 11, 2022 at 11:39 PM Domenic Denicola <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, Feb 11, 2022 at 11:53 AM Olli Pettay <[email protected]> >>>> wrote: >>>> >>>>> FWIW, the comment in the HTML spec triage was positive feedback to >>>>> have a spec for this. >>>>> The current spec proposal clearly is missing still quite a few cases >>>>> (is the idea really that one can use BroadcastChannel with prerendered >>>>> page? and the webidl annotation behaves rather oddly) >>>>> So it is surprising to see this shipping already now. >>>>> >>>> >>>> Thanks for chiming in, Olli! >>>> >>>> I have a rather different take. As the team's spec mentor, I'm >>>> impressed with the spec work the team has done, on taking what most other >>>> browsers have treated as a not-to-be-specified user agent UI feature, and >>>> turning it into something much more rigorous and developer-friendly. For >>>> example: >>>> >>>> - The careful auditing of all APIs to see how they should behave in >>>> prerendering. >>>> - Introducing a well-specified Sec-Purpose: prefetch header, >>>> instead of the unspecified X-moz: prefetch or X-Purpose: preview >>>> headers. >>>> - Considering how to handle edge cases such as redirects, 204s, >>>> Content-Disposition: attachment, or pages that do client-side >>>> navigation >>>> while being prerendered. >>>> >>>> I think there's definitely still work to be done, as we try to move >>>> from the current world where every browser does something different into >>>> one that's more fully predictable for web developers. But I think this is >>>> similar to other features, like bfcache, where for many years the >>>> heuristics and rules used were unspecified (e.g. Cache-Control, unload >>>> handlers, BroadcastChannel), and then we've started a slow convergence >>>> process as browsers start to care more about interoperability. >>>> >>>> We can definitely tweak things, like Olli's example of >>>> BroadcastChannel, over time and as other browsers indicate willingness to >>>> converge. >>>> >>> >>> One potential problem with that approach is that sites may grow to rely >>> on that existence of e.g. BroadcastChannel and may break when we take that >>> away. >>> I don't think that's a risk for the current I2S, as developers are not >>> aware that the page is being prerendered outside of the page itself, so the >>> chances of them trying to communicate with it are low. >>> But that can be a risk for the speculation rules based API, which would >>> be good to mitigate. >>> >>>> >>>> Re. BroadcastChannel and friends - it's a totally valid point and >> there's an open issue about it ( >> https://github.com/WICG/nav-speculation/issues/113). I feel that we >> should examine these especially as we move from omnibox to >> document-initiated prerenering. >> > > Yeah, just to be clear, I agree page-initiated prerendering multiplies the > risks significantly and will thus need more work. I expect there will > still be some implementation-dependent behavior (e.g., some implementations > may discard a prerender if they use a disruptive API, while others might > delay the API results). But things like "does BroadcastChannel work at all > or not" are critical to nail down for interoperable page-initiated > prerendering. > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/15f1995e-e8e8-4851-9607-69116672dfe5n%40chromium.org.
