Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav Weiss wrote: I ran into a Chromium-internal case where having a `close` signal would've helped me reduce complexity significantly. So I'm very excited about this work. I also believe

[blink-dev] Intent to Deprecate: Deprecate unload event

Contact emails fer...@chromium.org, kenjibah...@chromium.org Explainer https://github.com/fergald/docs/blob/master/explainers/permissions-policy-deprecate-unload.md Specification https://github.com/whatwg/html/pull/7915 Summary A Permission-Policy for creating unload event listeners will be

[blink-dev] Re: Intent to Prototype: Web Translation API

We are splitting the implementation of this into translate and language detection. So as well as the previous status entry , there is now a separate language detection API status entry , F On

[blink-dev] Intent to Prototype: Permissions-Policy: unload

Contact emails fer...@chromium.com, bfcache-dev Explainer https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md Specification https://github.com/whatwg/html/pull/7915 Summary This feature allows pages to disable the running of unload event handlers. The goal is

[blink-dev] Ready for Trial: Permission-Policy: unload

Contact emailsfer...@chromium.com Explainer https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md Specificationhttps://github.com/whatwg/html/pull/7915 Summary This feature allows pages to disable the running of unload event handlers. The goal is to : - allow sites

[blink-dev] Intent to Experiment: Permissions-Policy: unload

Contact emailsfer...@chromium.org Explainer https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md Specificationhttps://github.com/whatwg/html/pull/7915 Summary This feature allows pages to disable the running of unload event handlers. The goal is to : - allow sites

[blink-dev] FYI BFCacheing pages with dedicated workers

FYI, we are about to start a finch experiment to enable BFCaching of pages with Dedicated Workers. This is not an I2S because there's no new API or new capabilities. It's just another existing feature that used to block BFCache but won't anymore. Also, WebKit and Mozilla already do this. That said

ThRe: [blink-dev] Web-Facing Change PSA: NotRestoredReasons name change

This has been submitted as https://chromiumdash.appspot.com/commit/af269bab5f16b6a8304f1b820bca16c5118943f2 and will roll out in M135. Thanks, F On Tuesday, February 25, 2025 at 6:54:08 PM UTC+9 Fergal Daly wrote: > I would like to rollout this change in M135 (cutting next week). There

Re: [blink-dev] Web-Facing Change PSA: NotRestoredReasons name change

I would like to rollout this change in M135 (cutting next week). There has been no response to Domenic's argument that this is *very unlikely* to cause breakage. Unless someone argues that this needs to be more than a PSA, I will proceed, Fergal On Wednesday, November 13, 2024 at 6:11:08 PM UT

[blink-dev] Re: Intent to Ship: Clear BFCache during browsing data removal

I need to add some context to this I2S. This has already shipped. I just noticed a couple of days ago that this was not behind a flag and had already shipped. The work was done in prep for CCNS/BFCache, so in my head it was all coming together under one I2S. Apologies for that, F On Tue, 1 Aug

Re: [blink-dev] Intent to Ship: Clear BFCache during browsing data removal

On Tue, 1 Aug 2023 at 23:44, Mike Taylor wrote: > On 8/1/23 7:54 AM, 'Mingyu Lei' via blink-dev wrote: > > Contact emails le...@chromium.org, fer...@chromium.org > > Explainer None > > Specification None > > Given that WebKit is shipping this and we would like to, any reason to not > document thi

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

load and to not allow synchronous > XHRs on page unload were shipped. Both of those changes followed > essentially the same plan I just laid out above, and so I think it's > reasonable to do the same thing here. > > > On Thursday, June 29, 2023 at 7:02:06 AM UTC-7 Rick Byers

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

deprecated tab or the main tab, F > > On Mon, Aug 7, 2023 at 3:35 AM Fergal Daly wrote: > >> >> >> On Sat, 8 Jul 2023 at 07:55, Brandon Heenan wrote: >> >>> Hello, I'm chiming in to provide some thoughts from the enterprise >>> perspe

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

On Wed, 9 Aug 2023 at 12:01, Domenic Denicola wrote: > I think specifying these reasons is important. As noted in the linked > issue , I > think the end goal should be: > >- Every reason that a browser ever emits, is found in a spe

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

e is that the page says "These features are disabled by default. They will not be available in future versions of Chrome." This doesn't quite match what we are doing. > > On Tue, Aug 8, 2023 at 12:18 AM Fergal Daly wrote: > >> On Tue, 8 Aug 2023 at 08:00, Brand

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

though they are currently same origin >> in the use cases we care about most. >> >> The typical use case would be an ebook reader that has a container frame >> (the host) with book navigation controls, and a child frame (the guest) >> that contains the content for the cu

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

ers on > the thread? > That sounds great to me, F > > On Thu, Aug 10, 2023 at 4:33 AM Fergal Daly wrote: > >> On Wed, 9 Aug 2023 at 07:23, Brandon Heenan wrote: >> >>> Still, previous breaking changes to the unload event that affected SAP >>> were

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

ractices... >>> >>> >>> We expect that there will be cases where pages are restored >>> inappropriately where sites are not following good practice. We don't have >>> an idea of the size of this problem. We will have data from the beta >>> cha

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

lem. We will have data from the beta >> channel soon that will tell us what the difference would be in terms of >> BFCache hit-rate between *monitoring all cookies* and *only monitoring >> HttpOnly cookies*. Our thought process looks like this: >> >> If *monitoring all cookie

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

Cache. Again, it comes down to a trade-off between some small number of sites who have very short timeouts vs the performance benefit, F > /Daniel > On 2023-09-01 10:05, 'Fergal Daly' via blink-dev wrote: > > Sorry for the slow reply, I've had to focus on some ot

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

y traffic in UKM for a value of N that may increase as we gather data). This will avoid enterprise vendor instances while still allowing us to get started with the deprecation, F On Thu, 10 Aug 2023 at 20:33, Fergal Daly wrote: > On Wed, 9 Aug 2023 at 07:23, Brandon Heenan wrote: > >>

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

10 minute cache timeout. I'm well aware of sites that time out >>> authentications server side after a couple of minutes of inactivity and I >>> guess 3 would be in the same ball park. Did you pick that particular number >>> for any particular reason. Is it the

[blink-dev] Re: [Call for feedback] Proposal to gradually skip unload events: already unreliable, top back/forward cache blocker, better alternatives available!

me is navigating and potentially entering BFCache. So you I think you wouldn't want to free resources. If it is BFCached, then you may be restored. If it doesn't enter BFCache or is never restored then your resources will be freed anyway as everything is being destroyed. F > > Tha

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

he page just randomly changed over the timeout's period, which are > not scary) > > On Mon, Sep 11, 2023 at 12:32 PM Vladimir Levin > wrote: > >> >> >> On Mon, Sep 11, 2023 at 8:46 AM 'Fergal Daly' via blink-dev < >> blink-dev@chromium.org>

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

On Thu, 12 Oct 2023 at 23:05, Yoav Weiss wrote: > > > On Thu, Oct 12, 2023 at 3:56 PM Vladimir Levin > wrote: > >> Are there any spec changes planned for this feature? I'm not sure if the >> README linked under Specification is meant to make it into WHATWG, maybe to >> close out https://github.c

[blink-dev] Re: [Call for feedback] Proposal to gradually skip unload events: already unreliable, top back/forward cache blocker, better alternatives available!

20all%20cases%20where%20the%20unload%20event%20currently%20fires,%20and%20it%20also%20fires%20when%20a%20page%20is%20put%20in%20the%20bfcache.>, >> *pagehide *events should be a superset of *unload*. >> >> Thanks >> Kevin >> On Wednesday, March 29, 2023 at 11:23:

[blink-dev] Re: [Call for feedback] Proposal to gradually skip unload events: already unreliable, top back/forward cache blocker, better alternatives available!

workflows being messed up? If so, how do we join? > > The earliest version this will be enabled in is M120 which released in Jan. So that should be safe https://chromiumdash.appspot.com/schedule F > > On Wednesday, October 25, 2023 at 4:31:38 AM UTC-7 Fergal Daly wrote: > >> O

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

gt; new security issues. >> >> On Friday, October 13, 2023 at 7:14:46 AM UTC-7 vmp...@chromium.org >> wrote: >> >> On Fri, Oct 13, 2023 at 12:00 AM 'Fergal Daly' via blink-dev < >> blin...@chromium.org> wrote: >> >> On Thu, 12 Oct 2023

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

n there being a published document outlining the >>> options for web developers (i.e. the document you are already working on). >>> >>> /Daniel >>> On 2023-11-10 09:45, Fergal Daly wrote: >>> >>> On Fri, 10 Nov 2023 at 17:29, Yoav Weiss wrote: >>>

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

16 Nov 2023 at 13:37, Fergal Daly wrote: > Thanks everyone. Yes we will keep this thread up to date before releasing > this (we'll go to canary/dev very soon so that we start getting stability > and impact signals), > > F > > On Thu, 16 Nov 2023 at 05:30, Vladimir Levin

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

up in discussions of a back-preview (e.g. on mobile when gesturing the go back, we could show a snapshot of the page) and the intention there is to never do this with CCNS pages, F > > Thanks again for the write up > Vlad > > On Tue, Dec 5, 2023, 19:37 'Fergal Daly' via

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

On Wed, 6 Dec 2023 at 13:55, Fergal Daly wrote: > On Wed, 6 Dec 2023 at 12:29, Vladimir Levin wrote: > >> Thank you for the update! >> >> This is a good write up. One comment / question below >> >> From the doc: >> > Note that the pageshow event wi

Re: [blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

On Thu, 7 Dec 2023 at 01:07, Vladimir Levin wrote: > > > On Wed, Dec 6, 2023 at 1:16 AM 'Fergal Daly' via blink-dev < > blink-dev@chromium.org> wrote: > >> >> >> On Wed, 6 Dec 2023 at 13:55, Fergal Daly wrote: >> >>> On Wed, 6 Dec

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

s good, I will create a list on the explainer >>>> <https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md> >>>> for the "may block" reasons then. >>>> >>>> Re: exposing NotRestoredReasons interface inste

[blink-dev] Re: [Call for feedback] Proposal to gradually skip unload events: already unreliable, top back/forward cache blocker, better alternatives available!

On Wed, 8 Nov 2023 at 21:07, Fergal Daly wrote: > > > On Thu, 26 Oct 2023 at 01:11, Kevin D. > wrote: > >> Understood. >> >> >>1. *Is there any action required from us until general rollout (when >>`unload` isn’t fired anymore)?* >

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

On Wed, 7 Feb 2024 at 12:26, Domenic Denicola wrote: > > > On Tue, Feb 6, 2024 at 6:40 PM Fergal Daly wrote: > >> On Tue, 6 Feb 2024 at 15:13, Domenic Denicola >> wrote: >> >>> I am happy with the spec progress here and don't think it's a >

[blink-dev] Re: [Call for feedback] Proposal to gradually skip unload events: already unreliable, top back/forward cache blocker, better alternatives available!

[+sm...@mozilla.com] I'm relaying a piece of feedback from Mozilla in this github issue . It's possible that pages are depending on `unload` handlers in subframes for functionality even without any main frame navi

[blink-dev] Re: [Call for feedback] Proposal to gradually skip unload events: already unreliable, top back/forward cache blocker, better alternatives available!

more existing >> group policies." from the proposal since we got feedback that it's better >> to keep group policy free of any automated logic. >> >> I've reached out to a few more communities and have only heard supportive >> comments so far (touching wood)

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

g-API if you attempt to install a handler that is disallowed by policy. > > A couple more questions / comments inline: > > On Mon, May 8, 2023 at 7:43 AM Fergal Daly wrote: > >> Contact emails >> >> fer...@chromium.org, kenjibah...@chromium.org >> >> Explaine

[blink-dev] Re: FYI BFCacheing pages with dedicated workers

by default now, F On Fri, 26 May 2023 at 03:51, Aaron Grogg wrote: > Initial message dated May 7, 2022, but no updates or notes since... > > Curious as to the status of this; still a blocker, or resolved? > > Thanks! > Atg > > > On Monday, March 7, 2022 at 7:28:13

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

e can just go with the currently specced behaviour (don't run `unload` if BFCaching is possible) and maybe revert the PP:unload, F On Tue, 9 May 2023 at 16:01, Fergal Daly wrote: > On Mon, 8 May 2023 at 17:51, Rick Byers wrote: > >> Hi Fergal, >> It's exciting to see thi

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

ome discussion >> <https://github.com/w3c/webappsec-permissions-policy/issues/513#issuecomment-1564361739> >> about how Permissions-Policy off-by-default should work. Our current >> version requires every page to set the header and every parent to set the >> iframe `a

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

On Thu, 29 Jun 2023 at 14:41, Mike Taylor wrote: > Hi Fergal, > > Nice to have lunch with you today. > On 6/28/23 5:06 PM, 'Fergal Daly' via blink-dev wrote: > > Hi API-owners, > > > I am now asking for permission to go ahead with the following con

[blink-dev] Intent to Ship: Permissions-Policy: unload

Contact emailsfer...@chromium.org, kenjibah...@chromium.org Explainer https://github.com/fergald/docs/blob/master/explainers/permissions-policy-unload.md Specificationhttps://github.com/whatwg/html/pull/7915 Design docs https://github.com/fergald/docs/blob/master/explainers/permissions-policy-un

[blink-dev] Re: Intent to Ship: HTTPS pages with Cache-control: no-store and Back/Forward Cache

[BCC chrome-bfca...@google.com] On Tue, 11 Jul 2023 at 15:16, Mingyu Lei wrote: > +chrome-bfcache > > On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei wrote: > >> Contact emailskenjibah...@chromium.org, fer...@chromium.org, >> denom...@chromium.org, le...@chromium.org >> >> Specification >> https://

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

t;>be friction here. The two escalations mentioned above both resulted in >>>>>respins the first time they reached this point. However, this time >>>>> around, >>>>>IT admins will be able to fix their environment immediately with t

Re: [blink-dev] Intent to Deprecate: Deprecate unload event

At some point in the future, we expect to remove those mitigations and >remove support for the unload event completely. We don't have any specific >dates for that yet; we will be responsive to the needs of web stakeholders, >enterprise and otherwise. > > The two escalations I

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

>not restored reason strings, beyond the specified "fetch", >>"navigation-failure", "parser-aborted", "websocket", "lock", and "masked"? >> >> > We plan to add user-agent specific reasons to the spec in the

Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

On Thu, 22 Feb 2024 at 18:03, Domenic Denicola wrote: > > > On Thu, Feb 22, 2024 at 6:01 PM Fergal Daly wrote: > >> >> >> On Thu, 22 Feb 2024 at 16:32, Domenic Denicola >> wrote: >> >>> >>> >>> On Thu, Feb 22, 2024 at 4

Re: [blink-dev] Intent to Prototype: Web Translation API

On Tue, 30 Apr 2024 at 18:08, Daniel Vogelheim wrote: > Hi Domenic, et al., > > This intent came up in the OWP sec review today. We wonder whether there's > XSS potential, and how input with plain text interspersed with tags is > meant to be handled: > > Several of the use cases seem to hint at t

Re: [blink-dev] Intent to Experiment: Declarative Beacon API

Sorry, there were some details left out of this I2E. We actually have a lot of signals from web devs on this. There are some comments on https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776 but we also presented this to W3C WebPerf with a lot of positive signals. M

[blink-dev] Intent to Prototype: Inactive document invalidation API

Contact emailsfer...@chromium.org, yu...@chromium.org Explainerhttps://github.com/fergald/explainer-bfcache-ccns/blob/main/api.md Specification Summary An API that allows pages to declare triggers that will cause them to be invalidated (evicted from BFCache or cancelled from Prerendering). The

Re: [blink-dev] Intent to extend origin trial: Pending Beacon API

On Mon, 28 Nov 2022 at 14:55, Yoav Weiss wrote: > LGTM to continue experimentation till M112 inclusive. Note that any > extensions beyond that would require showing substantive progress towards > shipping (evidence of feedback addressed, draft specification, etc). > Having moved to a 4-week rele

Re: [blink-dev] Intent to extend origin trial: Pending Beacon API

On Mon, 28 Nov 2022 at 15:18, Fergal Daly wrote: > On Mon, 28 Nov 2022 at 14:55, Yoav Weiss wrote: > >> LGTM to continue experimentation till M112 inclusive. Note that any >> extensions beyond that would require showing substantive progress towards >> shipping (eviden

[blink-dev] Re: [3-7008000039495] merchant center email access

People from the team are responding on the bug I filed (b/427943772). It seems the account in question has added multiple mailing lists. They might just make it impossible to add mailing lists. That would solve this issue, F On Thu, 26 Jun 2025 at 17:39, 'Google Ads Scripts Direct Support' via bf