Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

LGTM3 Discussed a bit in API owners meeting today. There are some risks here, but IMHO it's all stuff we should be able to measure, detect and respond to (eg. if sites actually get slower due to incorrect use of this API). So those concerns don't seem worth blocking on to me. On Wed, Dec 25, 2024

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

Thanks Mike and Yoav. Acknowledging the non-blocking follow up work. On Fri, Dec 20, 2024 at 3:14 PM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote: > LGTM2 > > +1 for a continuous holdback study that can help us detect abuse resulting > in real-life regressions. > > On Wednesday, Decembe

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

LGTM2 +1 for a continuous holdback study that can help us detect abuse resulting in real-life regressions. On Wednesday, December 18, 2024 at 5:54:54 PM UTC+1 Mike Taylor wrote: > LGTM1 to ship, with some non-blocking homework. > > Could you please do the work to add a DevTools Issue so develop

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

LGTM1 to ship, with some non-blocking homework. Could you please do the work to add a DevTools Issue so developers are aware when this hint is harming performance rather than helping? It would also be good to try to do some HTTP Archive queries (or have a use counter, if that's feasible) to h

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

Sorry, yes, we ran as a separate thread until a few years ago. I'd forgotten that things got moved back. A worklet for handling these fetch types wouldn't be bound to any specific execution location (it's environment would be pretty austere; not the whole regular JS heap) and would likely only

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

Re: the consent management use case — that's right; a directive that disables speculative scan explicitly would help the consent use case more. However, future optimizations would find it difficult to wiggle out of such a contract. Hence a hint was chosen. From what Transcend described on the issue

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

The consent manager case seems particularly brittle, as any future improvements to reduce parser blockage by

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

Re: additional interest, Transcend.io had expressed interest in using the feature for preventing the preload scanner from loading URLs in sensitive contexts, prior to consent (non-performance improvement use case). Search is currently the on

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

Hey, We discussed this at API Owners today: 1. As Stephen mentioned, it would be nice if there was more support for this feature. Do you have partners or developers that are aware of this and are looking forward to using the feature? 2. In terms of approving this feature, we typically want the s

Re: [blink-dev] Intent to Ship: Document-Policy: expect-no-linked-resources

On Tue, Dec 10, 2024 at 11:08 PM Chromestatus < ad...@cr-status.appspotmail.com> wrote: > Contact emails ale...@google.com > > Explainer > https://github.com/explainers-by-googlers/expect-no-linked-resources > https://explainers-by-googlers.github.io/expect-no-linked-resources > > Specification ht