On Tue, May 10, 2022 at 8:41 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > On Thu, Apr 14, 2022 at 12:36 AM Jeremy Roman <jbro...@chromium.org> > wrote: > >> Contact emails >> >> jbro...@chromium.org, kenjibah...@chromium.org >> >> Explainer >> >> https://github.com/WICG/nav-speculation/blob/main/triggers.md >> >> Specification >> >> https://wicg.github.io/nav-speculation/speculation-rules.html >> >> https://wicg.github.io/nav-speculation/prefetch.html >> >> Summary >> >> Flexible syntax for defining what outgoing links are eligible to be >> prepared speculatively before navigation. Enables access to additional >> enhancements, such as use of a private prefetch proxy, where applicable. >> > > So IIUC, this intent is for shipping cross-origin prefetch? Where have > y'all landed on the question of cache partitioning? Which partition is > storing this prefetched resource? > It is isolated from any existing cache partition, and if the user does not then navigate to the prefetched resource it is not stored further. This is limited to the "prefetch" action, and does not include "prerender". >> The Chrome setting (extended preloading) which allows any site to request >> use of the private prefetch proxy and was previously mentioned on intents >> for this feature, is currently disabled for policy reasons but can be >> exposed via Finch as part of a launch, if approved. >> >> Blink component >> >> Internals>Preload >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3EPreload> >> >> TAG review >> >> https://github.com/w3ctag/design-reviews/issues/611 >> https://github.com/w3ctag/design-reviews/issues/721 >> > > https://github.com/WICG/nav-speculation/issues/160 which seems like > something we'd want to resolve before shipping. > Are y'all considering this new syntax? > Would it make sense to run this by your OT participants and/or partners? > Web developers in general? > The reason I don't think so is that this intent includes only more basic rules which supply a list of URLs, and extending the syntax to allow developers to select URLs from the links in the page is a future enhancement, albeit one I'm personally excited about. I don't expect that choices about how to express such selectors to cause compatibility issues with plain list-of-URLs rules. >> TAG review status >> >> First is complete, second is pending. >> >> Risks >> >> Interoperability and Compatibility >> > > Which of the 24 issues <https://github.com/WICG/nav-speculation/issues> > open on the repo is relevant for this intent? Can you highlight those that > may impact future compat and interop? > It's intended that such issues be labelled with speculation-rules or prefetch (indicating they affect one of the two pieces this would ship) and affects-compat. At the moment, the only such issue is this one <https://github.com/WICG/nav-speculation/issues/133>, which I believe is resolved as to prefetch. Looking again, any followup discussion (e.g. regarding subresources in prerenders) fit better in another issue, so I've closed that one. This issue <https://github.com/WICG/nav-speculation/issues/158> is not so labelled, though it's marginal and arguably could be. There is some ongoing discussion (which might become a whatwg/html issue shortly) connected to it about when user agents should observe modification and removal. While I would like to resolve this shortly, I expect the practical change to be relatively small and if anything in the direction of providing somewhat stronger guarantees rather than weaker ones. Most of the issues are with respect to either other features or enhancements which are likely to evolve in a way that is compatible with this. >> >> Gecko: No signal ( >> https://github.com/mozilla/standards-positions/issues/620) >> >> WebKit: No signal ( >> https://lists.webkit.org/pipermail/webkit-dev/2022-March/032158.html) >> >> Web developers: Some positive signal from a developer using the feature, >> and from a developer operating a site that is prefetched using this feature. >> > > It'd be good to externalize such feedback if at all possible. Any links? > I'll ask. >> Other signals: >> >> WebView Application Risks >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> >> >> Debuggability >> >> Limited, though fixing crbug.com/1315706 should provide basic insight >> and I'm not aware of anything that would preclude us from adding more >> sophisticated developer tools integration in the future. >> >> Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ? >> >> Tests are being landed at speculation-rules/prefetch/ in the WPT >> directory. We are continuing to work on adding more, though coverage in >> some areas will require the completion of some ongoing refactoring and >> additional test integration. >> >> Flag name >> >> The origin trial name is SpeculationRulesPrefetch. Some code internally >> calls this SpeculationRulesPrefetchProxy, but is not limited to proxied >> prefetches exclusively. >> >> Requires code in //chrome? >> >> Some code exists in chrome/, but refactoring work is underway to migrate >> as much of this as reasonable to content/. Some code specific to, e.g., the >> specific Google proxy service, will remain in chrome/. >> >> Tracking bug >> >> https://bugs.chromium.org/p/chromium/issues/detail?id=1173646 >> >> Estimated milestones >> >> M103 (Android) >> >> Since the current origin trial ends after M101, we would like to extend >> the experiment until shipping and request a gapless launch. >> >> I believe a gapless launch is justified here. The speculation rules API >> has been used by developers as part of this launch and the prerendering >> experiment >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Kpp6uJJRrqI/m/GTo_aF0qEQAJ>. >> There is an ongoing early access program >> <https://github.com/buettner/private-prefetch-proxy/issues/15> for >> publishers to opt in to receiving IP-obscured traffic enabled by this >> feature, and have received positive feedback about this program – which is >> planned to launch by default in coordination with this web platform side >> launch. Enforcing a gap here would interrupt this and require the private >> prefetch proxy team to notify affected partners (who are receiving prefetch >> traffic, rather than being direct users of this API), for no known benefit >> in this case. >> >> Shipping on desktop is not possible at this point due to extensions. We >> expect to file a separate Intent to Ship in the future. >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5740655424831488 >> >> Links to previous Intent discussions >> >> Intent to prototype: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/1q7Fp3zpjgQ >> >> Intent to Experiment: >> https://groups.google.com/a/chromium.org/g/blink-dev/c/Cw-hOjT47qI/m/EObn9-4MAgAJ >> >> Intent to Extend Experiment: >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cKaJB%3D2GQS4N3om1eSmuCVOY5zXchRCV8oCYkcq8kH0g%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cKaJB=2gqs4n3om1esmucvoy5zxchrcv8ocykcq8k...@mail.gmail.com> >> >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com/>. >> >> -- >> 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 blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cbVXw9nEo4zVwhGz_W65kfg0neYDqW3sMQC%2BYNzX6kfg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13cbVXw9nEo4zVwhGz_W65kfg0neYDqW3sMQC%2BYNzX6kfg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuR13eCJQjfm3Kn52%3D%2Bd-6rwOGTj6%2BsRbpgZoBdFTTcdpaHyw%40mail.gmail.com.
