Request for Deprecation Trial : HTMLVideoElement-specific Prefixed Fullscreen API

[Thomas Guilbert]

Contact emails

tgui...@chromium.org

Explainer

None

Specification

https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled

Summary

There was an attempt in 2014 to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen APIs. This meant removing the following APIs from HTMLVideoElement:

readonly attribute boolean webkitSupportsFullscreen;

readonly attribute boolean webkitDisplayingFullscreen;

void webkitEnterFullscreen();

void webkitExitFullscreen();

// Note the different capitalization of the "S" in FullScreen.

void webkitEnterFullScreen();

void webkitExitFullScreen();

The overall usage of these APIs is low, and has trended downwards over time. Here are the latest usage numbers, as a % of total page loads:

PrefixedVideoSupportsFullscreen: 0.025%

PrefixedVideoDisplayingFullscreen: 0.082%

PrefixedVideoEnterFullscreen: 0.001%

PrefixedVideoExitFullscreen: 0.010%

PrefixedVideoEnterFullScreen: 0.001%

PrefixedVideoExitFullScreen: 0.000%

There has been an unfortunate uptick in the past 2 years for the two following APIs, which means that it's best to remove them now, before they see a wider adoption. These numbers might be going up because the prefixed APIs are also present on iOS.

https://chromestatus.com/metrics/feature/timeline/popularity/166
https://chromestatus.com/metrics/feature/timeline/popularity/167

There is an alternative set of APIs supported by all browsers that web authors can use.

The full history of the removal attempt is here: crbug.com/346236

Goals for experimentation

The primary goal of the deprecation trial is to reduce the amount of broken user-visible experiences as the prefixed fullscreen APIs are removed, and to give time to web authors to transition to the modern API (which has been available for 5 years).

The un-prefixed fullscreen APIs have been available since Chrome M71.

Experiment timeline

TBD, with a proposed 3 months duration

Blink component

Blink>Fullscreen
Blink>Media>Video

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Web Compatibility:

Removing non-standard APIs should overall help web compatibility, and encourage web authors to use the unprefixed APIs. Some experiences might be broken by this change, thus justifying this deprecation trial. The API has been deprecated for a significant amount of time however, and usage has gone down.

This would only be an issue for websites that *only* support the prefixed APIs.

Interoperability:

All browsers have shipped the new APIs, most of them using an unprefixed version (Safari on iOS being the only remaining prefixed-only API). See also https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility

Gecko: 

WebKit: 

Web developers:

Other signals:

Activation

Impact on the Ads ecosystem:

N/A

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?

Potentially. The deprecation trial should give a heads up and appropriate time for apps to switch over to the unprefixed APIs.

Ongoing technical constraints

None

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes - the prefixed API will be removed across all platforms.

Is this feature fully tested by web-platform-tests?

Yes

WPTs testing the prefixes are removed: https://github.com/web-platform-tests/wpt/blob/master/fullscreen/api/historical.html

WPTs testing the new API: https://github.com/web-platform-tests/wpt/tree/master/fullscreen/api

Flag name on chrome://flags

None

Finch feature name

PrefixedVideoFullscreen

Non-finch justification

None

Requires code in //chrome?

False

Launch bug

None

Estimated milestones

DevTrial on desktop

123

DevTrial on Android

123

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5259513871466496

[Domenic Denicola]

It would be very exciting to clean this up! I have some questions that might help clarify the cost-benefit analysis.

On Sat, Jan 20, 2024 at 6:43 AM Thomas Guilbert <tgui...@chromium.org> wrote:

Contact emails

tgui...@chromium.org

Explainer

None

Specification

https://fullscreen.spec.whatwg.org/#dom-document-fullscreenenabled

Summary

There was an attempt in 2014 to deprecate and remove the HTMLVideoElement-specific Prefixed Fullscreen APIs. This meant removing the following APIs from HTMLVideoElement:

readonly attribute boolean webkitSupportsFullscreen;

readonly attribute boolean webkitDisplayingFullscreen;

void webkitEnterFullscreen();

void webkitExitFullscreen();

// Note the different capitalization of the "S" in FullScreen.

void webkitEnterFullScreen();

void webkitExitFullScreen();

How "expensive" is it to support these APIs? For example, if some of them are just straight-up aliases of standard APIs, then the benefit of removal might be low. Whereas if, for example, these prefixed "enter fullscreen" APIs have different behavior than the standardized requestFullscreen() API, then supporting the prefixed variants feels expensive, and getting rid of them is more worthwhile.

 

The overall usage of these APIs is low, and has trended downwards over time. Here are the latest usage numbers, as a % of total page loads:

PrefixedVideoSupportsFullscreen: 0.025%

PrefixedVideoDisplayingFullscreen: 0.082%

PrefixedVideoEnterFullscreen: 0.001%

PrefixedVideoExitFullscreen: 0.010%

PrefixedVideoEnterFullScreen: 0.001%

PrefixedVideoExitFullScreen: 0.000%

It's notable that the highest counters are for the boolean properties. That makes this slightly less risky, because removing them will cause them to return `undefined`, so code like `if (videoEl.webkitSupportsFullscreen) { ... }` will just return false, instead of throwing an exception or similar.

 

There has been an unfortunate uptick in the past 2 years for the two following APIs, which means that it's best to remove them now, before they see a wider adoption. These numbers might be going up because the prefixed APIs are also present on iOS.

https://chromestatus.com/metrics/feature/timeline/popularity/166
https://chromestatus.com/metrics/feature/timeline/popularity/167

I was going to ask about if there are popular sites or libraries using these, but I found some discussion of that in the bug. It seems like there's a hope that some sites already have fallbacks in place to the standardized APIs, but it's not quite clear. Maybe you could try running a build of Chromium with the prefixed APIs disabled on a random sampling of the HTTP Archive sites, and reporting back on if the user experience changes or new errors show up in the JS console? That could give us more confidence in the removal.

 

There is an alternative set of APIs supported by all browsers that web authors can use.

The full history of the removal attempt is here: crbug.com/346236

Goals for experimentation

The primary goal of the deprecation trial is to reduce the amount of broken user-visible experiences as the prefixed fullscreen APIs are removed, and to give time to web authors to transition to the modern API (which has been available for 5 years).

The un-prefixed fullscreen APIs have been available since Chrome M71.

Experiment timeline

TBD, with a proposed 3 months duration

Blink component

Blink>Fullscreen
Blink>Media>Video

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Web Compatibility:

Removing non-standard APIs should overall help web compatibility, and encourage web authors to use the unprefixed APIs. Some experiences might be broken by this change, thus justifying this deprecation trial. The API has been deprecated for a significant amount of time however, and usage has gone down.

This would only be an issue for websites that *only* support the prefixed APIs.

Interoperability:

All browsers have shipped the new APIs, most of them using an unprefixed version (Safari on iOS being the only remaining prefixed-only API). See also https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullscreen#browser_compatibility

Based on the WPT results, Gecko supports none of the prefixed APIs, and WebKit supports all of them. I think this is worth noting in the ChromeStatus entry. (Although it's not an official signal, so leave the dropdown at "No signals".)

Given this, filing a standards-positions issue on WebKit to get their take on the deprecation might be a good idea. Sometimes those discussions end up going in surprising directions; see e.g. this request for a position on the deprecation of mutation events.

(Gecko also has their own, smaller set of prefixed APIs. But it's not as relevant to this intent about the webkit-prefixed ones.)

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.com.

[Thomas Guilbert]

Good point about the most used APIs being the boolean properties! The APIs are now only aliases for the standard non-prefixed fullscreen APIs (see this code for the current implementation), and therefore aren't much of a burden to maintain.

I opened a WebKit standards position here: https://github.com/WebKit/standards-positions/issues/306

I unfortunately do not have access to edit the listed ChromeStatus entry, and the current owner no longer works on Chromium. Should I create a new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed Fullscreen API")? I think the current ChromeStatus entry also covers this API which I am not trying to deprecate in this Intent.

What's a reasonable sample size of HTTP Archive sites to audit? Should this be a complement/precursor to the proposed Deprecation Trial, or would this sampling be enough?

Thank you,

Thomas

[Domenic Denicola]

On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert <tgui...@chromium.org> wrote:

Good point about the most used APIs being the boolean properties! The APIs are now only aliases for the standard non-prefixed fullscreen APIs (see this code for the current implementation), and therefore aren't much of a burden to maintain.

I opened a WebKit standards position here: https://github.com/WebKit/standards-positions/issues/306

I unfortunately do not have access to edit the listed ChromeStatus entry, and the current owner no longer works on Chromium. Should I create a new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed Fullscreen API")? I think the current ChromeStatus entry also covers this API which I am not trying to deprecate in this Intent.

Yeah, I think a new feature is a good idea. The old feature seems to be for the addition of the prefixed fullscreen API properties back in Chrome 15, whereas a deprecation/removal has a different set of fields, if I understand correctly.

 

What's a reasonable sample size of HTTP Archive sites to audit? Should this be a complement/precursor to the proposed Deprecation Trial, or would this sampling be enough?

I recall +Philip Jägenstedt having done some computations in the past based on what would actually be statistically significant. But, I couldn't find them in this documentation (or the linked document). So, I'll just state that I would be happy with 20 sites.

I think the deprecation trial is a great complement to have in any case, so I would treat this as a precursor. It's always safest to have the option for web developers to un-break their sites. The purpose of the HTTP Archive investigation is mostly to see if we can find major shared patterns, to say things like "all sites using this code will be broken" or "all sites using this code will be slightly worse, but basically fine", or even "all sites using this open-source library will be broken, but we can send them a PR and that will create a clear upgrade path".

[Mike Taylor]

Would you mind requesting reviews for the various gates (privacy, security, debuggability) for an OT/DT in your chromestatus entry?

--

[Thomas Guilbert]

I've created a new ChromeStatus entry, and requested the privacy/security/debuggability gates for the deprecation trial.

I audited a little more than 20 sites from the HTTP Archive. I've found a few JS player libraries that primarily use the `webkitSupportsFullscreen` and `webkitDisplayingFullscreen` APIs: Mux and Clappr, and one instance of PlayerJS.

I found websites with a fullscreen button for Mux and PlayerJS, and they behaved as expected on a build of Chrome without the APIs. The one site I found using Clappr that had a fullscreen button did not work, both on the custom build and the latest canary.

It also seems like some version of the Vimeo CDN player uses `webkitEnterFullscreen`: https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js.

Thanks,

Thomas

[Thomas Guilbert]

I opened a support ticket with Mux, and opened an issue for Clappr.

[Wesley Luyten]

Wesley from Mux here. I saw the issue come by.

We'd be happy those API's could get deprecated and unified into the new one. 

Our Media Chrome (library, not browser) implementation handles this gracefully, some code here 
https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636

The Vimeo player uses a variant of https://github.com/bdougherty/BigScreen, a similar popular library is https://github.com/sindresorhus/screenfull

Just thought to mention it but iOS never supported the generic fullscreen API until very recent https://twitter.com/jensimmons/status/1717937227190460797
It always required the webkit prefixed API on the video element (not any other element like a div etc )

Y'all are aware of that?

[Domenic Denicola]

Thanks Thomas for all your work here! Your HTTP Archive survey seems promising to me: it sounds like there are no regressions, and you found some great places to perform outreach. (Hi Wesley!)

I'm happy to LGTM this as soon as the privacy/security reviews are approved and you've picked a target experiment timeline.

[Philip Jägenstedt]

On Tue, Jan 23, 2024 at 2:31 AM Domenic Denicola <dom...@chromium.org> wrote:

On Tue, Jan 23, 2024 at 7:55 AM Thomas Guilbert <tgui...@chromium.org> wrote:

Good point about the most used APIs being the boolean properties! The APIs are now only aliases for the standard non-prefixed fullscreen APIs (see this code for the current implementation), and therefore aren't much of a burden to maintain.

I opened a WebKit standards position here: https://github.com/WebKit/standards-positions/issues/306

I unfortunately do not have access to edit the listed ChromeStatus entry, and the current owner no longer works on Chromium. Should I create a new feature (titled "Deprecation of HTMLVideoElement-specific Prefixed Fullscreen API")? I think the current ChromeStatus entry also covers this API which I am not trying to deprecate in this Intent.

Yeah, I think a new feature is a good idea. The old feature seems to be for the addition of the prefixed fullscreen API properties back in Chrome 15, whereas a deprecation/removal has a different set of fields, if I understand correctly.

 

What's a reasonable sample size of HTTP Archive sites to audit? Should this be a complement/precursor to the proposed Deprecation Trial, or would this sampling be enough?

I recall +Philip Jägenstedt having done some computations in the past based on what would actually be statistically significant. But, I couldn't find them in this documentation (or the linked document). So, I'll just state that I would be happy with 20 sites.

You're probably thinking of these threads:

https://groups.google.com/a/chromium.org/g/blink-dev/c/gIyvMw0n2qw/m/CC7RlhguAgAJ

https://groups.google.com/a/chromium.org/g/blink-dev/c/V7q43bgutbo/m/GpJogpw4AgAJ

Checking 20 sites at random and finding no breakage gives us 95% confidence that the true occurence of broken sites is no more than ~17%. Checking 40 reduces that to ~9%. (Based on https://sample-size.net/confidence-interval-proportion/.) If the set we're sampling from is sites that hit a use counter, then it says something about the real risk of breaking that code path.

Checking 20 like Thomas did seems enough to me, we're starting from a low risk and just want to know if breakage is common or not. It seems to not be common even on sites that use the APIs.

[Philip Jägenstedt]

On Thu, Jan 25, 2024 at 2:00 AM Wesley Luyten <luyten...@gmail.com> wrote:

Wesley from Mux here. I saw the issue come by.

We'd be happy those API's could get deprecated and unified into the new one. 

Our Media Chrome (library, not browser) implementation handles this gracefully, some code here 
https://github.com/muxinc/media-chrome/blob/83c1a0f000bc8898971f030bcafa0d6df37cdc34/src/js/controller.js#L636-L636

Thanks for sharing! This code falls back to the standard media.requestFullscreen() API if media.webkitEnterFullscreen isn't available, so it won't break.

I suspect this order of feature detection could be common because the video-specific prefixed fullscreen APIs are the very oldest, followed by the generic prefixed APIs, and the standard APIs came around much, much later.

The Vimeo player uses a variant of https://github.com/bdougherty/BigScreen, a similar popular library is https://github.com/sindresorhus/screenfull

BigScreen seems to use the standard API if both are present, and screenfull doesn't deal with the video-specific prefixed APIs at all. So neither of these ought to explain usage we're seeing via use counters.

 

Just thought to mention it but iOS never supported the generic fullscreen API until very recent https://twitter.com/jensimmons/status/1717937227190460797
It always required the webkit prefixed API on the video element (not any other element like a div etc )

Y'all are aware of that?

Yeah, I was very happy to see that ship.

[Philip Jägenstedt]

I'm also happy to support a plan to deprecate and remove. The use counter that best represents worst-case user impact at https://chromestatus.com/metrics/feature/timeline/popularity/170 at ~0.001%. But that's only when fullscreen actually happens (on user interaction) and it's very hard to say what proportion of sites could potentially hit this code path, especially given the ubiquitous pattern of trying multiple API names that's been necessary forever with fullscreen, so that some sites will just fall back to a working API.

What timeline do you have in mind?

[Thomas Guilbert]

Thank you Wesley for the useful information!

> What timeline do you have in mind?

I'm not sure what reasonable timelines are, not having dealt with deprecations before. Is 3 months for a deprecation trial acceptable? Devtools should already have deprecation warnings, but I don't see them in my console.

I had looked at the only site listed for the https://chromestatus.com/metrics/feature/timeline/popularity/170  use-counter. They are directly calling the API for their overlay welcome video, but the page seemed to work fine with the API disabled. I don't think the fullscreen actually happens, without the user interaction...

This use counter shows a spike up from December to January https://chromestatus.com/metrics/feature/timeline/popularity/168. 5 links are using https://f.vimeocdn.com/p/4.27.1/js/vendor.module.js, one link is also playing an overlay video intro.

[Philip Jägenstedt]

https://sites.google.com/a/chromium.org/dev/blink/launching-features doesn't give any guidance on the timeline, so let's just pick a timeline that makes sense for this case. It's been up to a year in other cases.

Since feature detection is common, we have to remove the whole API surface and let code that depends on it throw exceptions. We won't be able to print anything helpful to the console informing developers that there is a deprecation trial. From their point of view it will simply be removed, and they might find out about the deprecation trial if they do some further research.

Since the cost of supporting these APIs is very low, I think we should give developers plenty of time. But usage is already so low that it's not a certainty that anyone will really use the trial. So how about we start with 6 months, and if we see that there are sites using the trial to re-enable the feature, then we extend it by another 6 months. Would that work?

[Thomas Guilbert]

Ok for a 6 months trial, with the possibility to extend it further. I will wait for the remaining security/privacy approvals and then update this thread again.

Additionally, someone commented on the WebKit positions standards thread that the next version of Safari will have support for the fullscreen API (still subject to change before shipping). It would be great timing if the API ships on iOS, to minimize the work for web authors as they switch away from the API.

[Philip Jägenstedt]

Thanks Thomas, looking forward to being able to say LGTM to this :)

I agree that it would be ideal if the unprefixed API is supported on iOS before we remove the video-specific prefixed APIs in Chrome, so that people can have confidence their updated code will work in both Chrome and Safari.

[Mike Taylor]

Gentle reminder to follow up on requesting privacy/security/debuggability approvals in chromestatus (which is currently blocking LGTMs).

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

Apologies in advance for excessive paperwork, but can you also put https://chromestatus.com/feature/5111638103687168 through the process, requesting enterprise signoff in particular? Enterprise folks could depend on this and might need to take some extra action, and a "Feature deprecation" entry is the only way we can flag that.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoa373%3Dnxuc%2BTe_h9e0WdS53_oAyUEa%2B4j0v2xWgJ2MFcw%40mail.gmail.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b1babe80-69c0-4f5e-b6f8-9d6c1ca20d9an%40chromium.org.

[Thomas Guilbert]

I requested privacy/security/debuggability on the video element fullscreen API deprecation feature last week. Privacy and debuggability are approved, just waiting on security.

Mike, are you talking about requesting those gates on the original Prefixed Fullscreen API feature? I don't have edit rights on that Chrome status entry, and upon closer look, it relates to `webkitRequestFullscreen`, which is not covered by this deprecation intent.

> [...] requesting enterprise signoff [...]

Is this a field on the chrome status entry? It doesn't show up for me. Or is this about emailing the list mentioned here?

Thanks,

Thomas

[Mike Taylor]

Yep - seems that's the cause of confusion. In your first email, https://chromestatus.com/feature/5259513871466496 is linked from the bottom, so our review tooling is presenting that to us. But I've just flagged the new one so it will show up as well.

thanks!

[Thomas Guilbert]

Thanks for marking it for review!

I submitted a request to review this change to the chromium enterprise mailing list.

Thanks,

Thomas

[Philip Jägenstedt]

Thank you Thomas!

As far as I'm aware that's all of the paperwork completed, so LGTM1 to disable the APIs by default and at the same time start a reverse origin trial to re-enable them for 6 months. If you hear feedback requesting an extension towards the end of those 6 months, please request an extension for another 6 months.

[Thomas Guilbert]

Thank you!

I will be adding an enterprise policy to re-enable the APIs if necessary, as part of the enterprise review. Deprecating the enterprise policy will become the new objective after the proper amount of time has elapsed, before the code can be deleted for good.

I will keep updating this thread as I make it further in the launch process.

[Domenic Denicola]

LGTM2. Please be sure to update Chrome Status with the deprecation trial timelines and removal milestones so that data gets fed into the feature dashboard, beta blog posts, etc.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoZW7%2B11bA89iRbRPBT4%2BEHDtUA0GRaud0zY9NrZwjmMRA%40mail.gmail.com.

[Mike Taylor]

LGTM3

[Thomas Guilbert]

FYI, the enterprise policy landed in M124 (under "PrefixedVideoFullscreenApiAvailability"), and the deprecation trial will activate when M125 branches, on April 15th.

[Thomas Guilbert]

The deprecation trial has been underway for ~6months. A small handful of websites have registered for the OT. M131 has branched, and is the last release with the deprecation trial.

Usage numbers have gone to 0 according to UMAs on M126+ (using the usecounters).

There is an uptick in calls for some of the APIs according to the Chromestatus use counters:

• https://chromestatus.com/metrics/feature/timeline/popularity/168
• https://chromestatus.com/metrics/feature/timeline/popularity/170
  
• https://chromestatus.com/metrics/feature/timeline/popularity/171

The relative usage has gone up, but the absolute usage remains very small. My hypothesis is: by checking for the presence of these APIs ahead of their removal, websites might be calling the APIs more frequently (when they are still present).

We had originally discussed potentially extending the OT by 6 months. I am not aware of any website being broken, and I have not come across any negative feedback (although I have not contacted the OT registrants yet).

My proposal would be to contact the OT registrants, and let them know that M131 is planned be the last release with the OT, and to extend the OT (3 months?) if ever there is pushback.

Does this sound like a reasonable plan? 

Thank you,

Thomas

[Chris Harrelson]

On Tue, Oct 15, 2024 at 1:39 PM Thomas Guilbert <tgui...@chromium.org> wrote:

The deprecation trial has been underway for ~6months. A small handful of websites have registered for the OT. M131 has branched, and is the last release with the deprecation trial.

Usage numbers have gone to 0 according to UMAs on M126+ (using the usecounters).

There is an uptick in calls for some of the APIs according to the Chromestatus use counters:

• https://chromestatus.com/metrics/feature/timeline/popularity/168
• https://chromestatus.com/metrics/feature/timeline/popularity/170
  
• https://chromestatus.com/metrics/feature/timeline/popularity/171

The relative usage has gone up, but the absolute usage remains very small. My hypothesis is: by checking for the presence of these APIs ahead of their removal, websites might be calling the APIs more frequently (when they are still present).

We had originally discussed potentially extending the OT by 6 months. I am not aware of any website being broken, and I have not come across any negative feedback (although I have not contacted the OT registrants yet).

My proposal would be to contact the OT registrants, and let them know that M131 is planned be the last release with the OT, and to extend the OT (3 months?) if ever there is pushback.

Does this sound like a reasonable plan? 

Hi Thomas, 

I'd prefer not to extend beyond M131, so I'm supportive of communicating M131 to them as a last release and leaving it at that. Especially since you haven't heard negative feedback.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoamwa6NdB_bEnTXy_Ro1%2Bg7Stq2-8Lr0zv_icMOGEAzvg%40mail.gmail.com.

[Thomas Guilbert]

The email was sent to OT registrants around October 25th. I have started an intent to (un)ship this feature, so discussion can continue on that thread:
https://groups.google.com/a/chromium.org/g/blink-dev/c/srGFORpjjI8

Thank you!