Intent to implement and ship: Media Session API: Video conferencing actions

[Tommy Steimel]

Contact emails

ste...@chromium.org

Explainer

https://github.com/w3c/mediasession/issues/264

Specification

https://w3c.github.io/mediasession/

Design docs

https://docs.google.com/document/d/1KDpWqg9LcnuQ5TQDBK45BrbkyfuziolZ0m7Wmt6xPnU/edit?usp=sharing&resourcekey=0-I0o3GayIn9Q-2LN7EB1l8w

Summary

Adds "togglemicrophone", "togglecamera", and "hangup" actions to the existing Media Session API. This will enable developers of video conferencing websites to handle these actions from browser UI. For example, if the user puts their video call into a picture-in-picture window, the browser could display buttons for mute/unmute, turnon/turnoff camera, and hang up. When the user clicks these, the website handles them through the Media Session API.

Blink component

Internals>Media>Session

TAG review

https://github.com/w3ctag/design-reviews/issues/608

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Interop risk is low because it's a small addition to an existing API

Gecko: No signal

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031761.html) Interested in WebRTC and hangup use cases

Web developers: Positive Same as Apple (see above), we received feedback from web developers that they would be interested to handle WebRTC sessions via Media Session.

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

No

Flag name

MediaSessionWebRTC

Tracking bug

https://crbug.com/1178939

Launch bug

https://crbug.com/1174645

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5744304695803904

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/0WrBY77sfh0/m/W60ozzztAwAJ

This intent message was generated by Chrome Platform Status.

[Thomas Steiner]

On Tue, Apr 6, 2021 at 2:22 AM 'Tommy Steimel' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ste...@chromium.org

Explainer

https://github.com/w3c/mediasession/issues/264

Specification

https://w3c.github.io/mediasession/

Design docs

https://docs.google.com/document/d/1KDpWqg9LcnuQ5TQDBK45BrbkyfuziolZ0m7Wmt6xPnU/edit?usp=sharing&resourcekey=0-I0o3GayIn9Q-2LN7EB1l8w

Summary

Adds "togglemicrophone", "togglecamera", and "hangup" actions to the existing Media Session API. This will enable developers of video conferencing websites to handle these actions from browser UI. For example, if the user puts their video call into a picture-in-picture window, the browser could display buttons for mute/unmute, turnon/turnoff camera, and hang up. When the user clicks these, the website handles them through the Media Session API.

Blink component

Internals>Media>Session

TAG review

https://github.com/w3ctag/design-reviews/issues/608

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Interop risk is low because it's a small addition to an existing API

Gecko: No signal

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031761.html) Interested in WebRTC and hangup use cases

Web developers: Positive Same as Apple (see above), we received feedback from web developers that they would be interested to handle WebRTC sessions via Media Session.

For Web-visible developer signals I suggest the engagements to this tweet: https://twitter.com/intenttoship/status/1371944489980399623 (3 ReTweets, 1 Quote Tweet, 7 Likes). 

 

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

No

Flag name

MediaSessionWebRTC

Tracking bug

https://crbug.com/1178939

Launch bug

https://crbug.com/1174645

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5744304695803904

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/0WrBY77sfh0/m/W60ozzztAwAJ

This intent message was generated by Chrome Platform Status.

--
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/CAE-AwAp3BWNF5KyPQ%3DfBXJRnA_3Gm2sQH5ModT%3DYF5AebKMXqA%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
-----END PGP SIGNATURE-----

[Yoav Weiss]

On Tue, Apr 6, 2021 at 2:22 AM 'Tommy Steimel' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ste...@chromium.org

Explainer

https://github.com/w3c/mediasession/issues/264

Specification

https://w3c.github.io/mediasession/

Design docs

https://docs.google.com/document/d/1KDpWqg9LcnuQ5TQDBK45BrbkyfuziolZ0m7Wmt6xPnU/edit?usp=sharing&resourcekey=0-I0o3GayIn9Q-2LN7EB1l8w

Summary

Adds "togglemicrophone", "togglecamera", and "hangup" actions to the existing Media Session API. This will enable developers of video conferencing websites to handle these actions from browser UI. For example, if the user puts their video call into a picture-in-picture window, the browser could display buttons for mute/unmute, turnon/turnoff camera, and hang up. When the user clicks these, the website handles them through the Media Session API.

Blink component

Internals>Media>Session

TAG review

https://github.com/w3ctag/design-reviews/issues/608

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Interop risk is low because it's a small addition to an existing API

Gecko: No signal

Have we asked for one? https://bit.ly/blink-signals

 

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031761.html) Interested in WebRTC and hangup use cases

Web developers: Positive Same as Apple (see above), we received feedback from web developers that they would be interested to handle WebRTC sessions via Media Session.

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

No

Why not? Is it tested by other means? Bugs filed to enable its testing in the future?

 

Flag name

MediaSessionWebRTC

Tracking bug

https://crbug.com/1178939

Launch bug

https://crbug.com/1174645

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5744304695803904

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/0WrBY77sfh0/m/W60ozzztAwAJ

This intent message was generated by Chrome Platform Status.

--

[Tommy Steimel]

On Tue, Apr 6, 2021 at 3:48 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tue, Apr 6, 2021 at 2:22 AM 'Tommy Steimel' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ste...@chromium.org

Explainer

https://github.com/w3c/mediasession/issues/264

Specification

https://w3c.github.io/mediasession/

Design docs

https://docs.google.com/document/d/1KDpWqg9LcnuQ5TQDBK45BrbkyfuziolZ0m7Wmt6xPnU/edit?usp=sharing&resourcekey=0-I0o3GayIn9Q-2LN7EB1l8w

Summary

Adds "togglemicrophone", "togglecamera", and "hangup" actions to the existing Media Session API. This will enable developers of video conferencing websites to handle these actions from browser UI. For example, if the user puts their video call into a picture-in-picture window, the browser could display buttons for mute/unmute, turnon/turnoff camera, and hang up. When the user clicks these, the website handles them through the Media Session API.

Blink component

Internals>Media>Session

TAG review

https://github.com/w3ctag/design-reviews/issues/608

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Interop risk is low because it's a small addition to an existing API

Gecko: No signal

Have we asked for one? https://bit.ly/blink-signals

Yep I asked for one here: https://github.com/mozilla/standards-positions/issues/504 

 

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031761.html) Interested in WebRTC and hangup use cases

Web developers: Positive Same as Apple (see above), we received feedback from web developers that they would be interested to handle WebRTC sessions via Media Session.

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

No

Why not? Is it tested by other means? Bugs filed to enable its testing in the future?

Just haven't done it yet. Filed crbug.com/1196466 

[Yoav Weiss]

Thanks for working on this! Seems like an important use case in our socially-distanced world.

On Wed, Apr 7, 2021 at 1:33 AM Tommy Steimel <ste...@google.com> wrote:

On Tue, Apr 6, 2021 at 3:48 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Tue, Apr 6, 2021 at 2:22 AM 'Tommy Steimel' via blink-dev <blin...@chromium.org> wrote:

Contact emails

ste...@chromium.org

Explainer

https://github.com/w3c/mediasession/issues/264 

Specification

https://w3c.github.io/mediasession/

Design docs

https://docs.google.com/document/d/1KDpWqg9LcnuQ5TQDBK45BrbkyfuziolZ0m7Wmt6xPnU/edit?usp=sharing&resourcekey=0-I0o3GayIn9Q-2LN7EB1l8w

Summary

Adds "togglemicrophone", "togglecamera", and "hangup" actions to the existing Media Session API. This will enable developers of video conferencing websites to handle these actions from browser UI. For example, if the user puts their video call into a picture-in-picture window, the browser could display buttons for mute/unmute, turnon/turnoff camera, and hang up. When the user clicks these, the website handles them through the Media Session API.

Blink component

Internals>Media>Session

TAG review

https://github.com/w3ctag/design-reviews/issues/608

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Interop risk is low because it's a small addition to an existing API

"Interop" can roughly translate to "will other browsers follow?". The signals from WebKit are encouraging on that front.

In the meantime, what's the backward compatibility story here? It's not clear from the initial issue (and would be good to clarify in a stand alone explainer, or in the initial comment on that issue).

Are developers expected to feature-detect support? Will new action handlers be ignored by non-supporting UAs?

 

Gecko: No signal

Have we asked for one? https://bit.ly/blink-signals

Yep I asked for one here: https://github.com/mozilla/standards-positions/issues/504 

 

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031761.html) Interested in WebRTC and hangup use cases

Web developers: Positive Same as Apple (see above), we received feedback from web developers that they would be interested to handle WebRTC sessions via Media Session.

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

No

Why not? Is it tested by other means? Bugs filed to enable its testing in the future?

Just haven't done it yet. Filed crbug.com/1196466 

Are you planning to land the tests before shipping?

[Tommy Steimel]

We've added new actions in the past and developers are expected to feature-detect support. Currently new action handlers raise errors on non-supporting UAs (so catching an error is a way to feature-detect). 

 

 

Gecko: No signal

Have we asked for one? https://bit.ly/blink-signals

Yep I asked for one here: https://github.com/mozilla/standards-positions/issues/504 

 

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031761.html) Interested in WebRTC and hangup use cases

Web developers: Positive Same as Apple (see above), we received feedback from web developers that they would be interested to handle WebRTC sessions via Media Session.

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

No

Why not? Is it tested by other means? Bugs filed to enable its testing in the future?

Just haven't done it yet. Filed crbug.com/1196466 

Are you planning to land the tests before shipping?

Yep. Since there are already existing tests for MediaSession, adding ones for these should be fairly quick 

[Yoav Weiss]

That's... suboptimal IMO, as it means that failure to feature detect would break the app, rather than just this specific functionality.

Seems like at the very least we need to make it extremely prominent in the explainer and any developer-facing documentation that they need to catch exceptions for this.

Do you know if past additions to the supported set went well in non-supporting browsers?

 

 

Gecko: No signal

Have we asked for one? https://bit.ly/blink-signals

Yep I asked for one here: https://github.com/mozilla/standards-positions/issues/504 

 

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031761.html) Interested in WebRTC and hangup use cases

Web developers: Positive Same as Apple (see above), we received feedback from web developers that they would be interested to handle WebRTC sessions via Media Session.

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

No

Why not? Is it tested by other means? Bugs filed to enable its testing in the future?

Just haven't done it yet. Filed crbug.com/1196466 

Are you planning to land the tests before shipping?

Yep. Since there are already existing tests for MediaSession, adding ones for these should be fairly quick 

Flag name

MediaSessionWebRTC

Tracking bug

https://crbug.com/1178939

Launch bug

https://crbug.com/1174645

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5744304695803904

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/0WrBY77sfh0/m/W60ozzztAwAJ

This intent message was generated by Chrome Platform Status.

--
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+unsubscribe@chromium.org.

[Mike Taylor]

On 4/7/21 1:48 PM, 'Tommy Steimel' via blink-dev wrote:
> On Wed, Apr 7, 2021 at 1:30 AM Yoav Weiss <yoav...@chromium.org
> <mailto:yoav...@chromium.org>> wrote:
> "Interop" can roughly translate to "will other browsers follow?".
> The signals from WebKit are encouraging on that front.
>
> In the meantime, what's the backward compatibility story here? It's
> not clear from the initial issue (and would be good to clarify in a
> stand alone explainer, or in the initial comment on that issue).
> Are developers expected to feature-detect support? Will new action
> handlers be ignored by non-supporting UAs?
>
>
> We've added new actions in the past and developers are expected to
> feature-detect support. Currently new action handlers raise errors on
> non-supporting UAs (so catching an error is a way to feature-detect).

Try/catch isn't a super common feature detection pattern in JS land, in
my experience, typically it's of the form: 'if ("foo" in bar) {bar.foo()}'.

Also, which kind of error? Just a generic TypeError?
https://w3c.github.io/mediasession/ doesn't really say anything on the
topic. Unfortunately there's a lot of evidence of developers only
testing in a single browser, so they may not even notice an error in
another browser.

Would it be possible to expose the "supported media session actions"[1]
such that developers could at least test for support in a way that
doesn't require try/catch (or worse, UA sniffing...), similar to
window.CSS.supports()[2]?

[1] <https://w3c.github.io/mediasession/#supported-media-session-actions>
[2] <https://developer.mozilla.org/en-US/docs/Web/API/CSS/supports>

[Mike Taylor]

Another thought: setActionHandler could just silently ignore actions it
doesn't support or understand, then feature detection becomes less
important for interop.

[Tommy Steimel]

I haven't been involved in past additions, so I'm not sure how exactly they went. I am supportive of ignoring unsupported actions instead of throwing an error, but that might be a spec change in itself. I think we would need to change setActionHandler() from taking a MediaSessionAction as its first argument to taking a DOMString.

Also, for this spec change the developer could just check that navigator.mediaSession.setMicrophoneActive exists before assuming these new actions exist, but I agree that in the longer term ignoring unsupported ones is cleaner/healthier/better.

[Tommy Steimel]

Looks like here is where the spec says that a function that takes an enumeration will throw an error on a bad value: https://www.w3.org/TR/WebIDL/#idl-enums. I also couldn't find a way for developers to access the MediaSessionAction enum in javascript (to check what values are in there).

Which means our options would be:

1) Change it to a DOMString like I mentioned before and ignore unsupported actions

2) Have a separate method that takes in a DOMString and returns a boolean indicating whether that string is a valid action

3) Have a separate method or attribute that lists all valid actions

4) Leave it as is and throw an error for unsupported actions

[Mounir Lamouri]

Hi,

Spec editor and WG chair here. Since the first version of this spec, three actions were added and while feature detection was discussed in the past, I do not think there was ever an issue on file. I don't think adding these new actions should be blocked by solving this (especially as Tommy said, there is a simple feature detection of the feature scope). And definitely Chrome shouldn't just go and implement changes without a discussion with the working group given the current x-browser support.

However, I think it would be fair for someone in Chrome to file an issue against the specification and add an "agenda" label. It would bring the issue to the next WG meeting (next week) and allow a discussion that would lead towards a better feature detection solution. FWIW, there was a larger discussion about enum (and dictionary) feature detection here: https://github.com/heycam/webidl/issues/107

As a side note, as someone who will have to use these actions, silent failure would be worse than throwing. It will certainly lead to my team doing a browser check instead of feature detecting as we would need to know if a given feature is supported.

Thanks,

-- Mounir

--

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/CAE-AwApQyR%2BWvD8knRgVRfZhwXvS65RPTB4%3DTZSsUEF%3DmoA_9Q%40mail.gmail.com.

[Yoav Weiss]

Hey Mounir! 

On Thursday, April 8, 2021 at 7:57:17 PM UTC+2 Mounir Lamouri wrote:

Hi,

Spec editor and WG chair here. Since the first version of this spec, three actions were added and while feature detection was discussed in the past, I do not think there was ever an issue on file. I don't think adding these new actions should be blocked by solving this (especially as Tommy said, there is a simple feature detection of the feature scope).

Adding these new actions runs a risk of breaking non-supporting sites if developers are not careful, so I believe discussing this is in scope.

 

And definitely Chrome shouldn't just go and implement changes without a discussion with the working group given the current x-browser support.

I don't think anyone's suggesting that.

 

However, I think it would be fair for someone in Chrome to file an issue against the specification and add an "agenda" label. It would bring the issue to the next WG meeting (next week) and allow a discussion that would lead towards a better feature detection solution.

That sounds great!

 

FWIW, there was a larger discussion about enum (and dictionary) feature detection here: https://github.com/heycam/webidl/issues/107

Agree that a generic solution would be very welcome here and elsewhere.

 

As a side note, as someone who will have to use these actions, silent failure would be worse than throwing. It will certainly lead to my team doing a browser check instead of feature detecting as we would need to know if a given feature is supported.

Agree that a silent failure is not great. I'd have preferred a return value for that purpose.

 

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

[Mounir Lamouri]

On Thu, 8 Apr 2021 at 11:54, Yoav Weiss <yoav...@chromium.org> wrote:

Hey Mounir! 

On Thursday, April 8, 2021 at 7:57:17 PM UTC+2 Mounir Lamouri wrote:

Hi,

Spec editor and WG chair here. Since the first version of this spec, three actions were added and while feature detection was discussed in the past, I do not think there was ever an issue on file. I don't think adding these new actions should be blocked by solving this (especially as Tommy said, there is a simple feature detection of the feature scope).

Adding these new actions runs a risk of breaking non-supporting sites if developers are not careful, so I believe discussing this is in scope.

In three different occasions this specification has had new actions and neither Chrome nor the specification received feedback that it was a problem.

 

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

[Yoav Weiss]

We discussed this at the API owners meeting just now (with Alex, Chris, Mike, Daniel, Rego and myself present).

On Thursday, April 8, 2021 at 8:54:57 PM UTC+2 Yoav Weiss wrote:

Hey Mounir! 

On Thursday, April 8, 2021 at 7:57:17 PM UTC+2 Mounir Lamouri wrote:

Hi,

Spec editor and WG chair here. Since the first version of this spec, three actions were added and while feature detection was discussed in the past, I do not think there was ever an issue on file. I don't think adding these new actions should be blocked by solving this (especially as Tommy said, there is a simple feature detection of the feature scope).

Adding these new actions runs a risk of breaking non-supporting sites if developers are not careful, so I believe discussing this is in scope.

 

And definitely Chrome shouldn't just go and implement changes without a discussion with the working group given the current x-browser support.

I don't think anyone's suggesting that.

 

However, I think it would be fair for someone in Chrome to file an issue against the specification and add an "agenda" label. It would bring the issue to the next WG meeting (next week) and allow a discussion that would lead towards a better feature detection solution.

That sounds great!

The API owners agreed that discussion in the WG sounds like the best way forward.

Tommy - would you be able to file the issue as Mounir suggested?

Then we can see if we can get a better feature detection mechanism that would de-risk adding new entries to that dictionary, and decide on a best course of action based on that.

[Yoav Weiss]

On Thursday, April 8, 2021 at 9:57:42 PM UTC+2 Mounir Lamouri wrote:

On Thu, 8 Apr 2021 at 11:54, Yoav Weiss <yoav...@chromium.org> wrote:

Hey Mounir! 

On Thursday, April 8, 2021 at 7:57:17 PM UTC+2 Mounir Lamouri wrote:

Hi,

Spec editor and WG chair here. Since the first version of this spec, three actions were added and while feature detection was discussed in the past, I do not think there was ever an issue on file. I don't think adding these new actions should be blocked by solving this (especially as Tommy said, there is a simple feature detection of the feature scope).

Adding these new actions runs a risk of breaking non-supporting sites if developers are not careful, so I believe discussing this is in scope.

In three different occasions this specification has had new actions and neither Chrome nor the specification received feedback that it was a problem.

I was only aware of us shipping one action after the initial API shipping. If we have evidence that developers are properly using try/catch statements and it's safe to ship more new actions, that can decouple the feature detection discussion from shipping these new actions.

Do you have pointers to newly introduced actions? Do you know if that passed without compat issues?

 

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

[Tommy Steimel]

I want to note that this won't break any existing websites (it's not clear to me if that's what you're implying by "safe to ship new actions" in this context, but I wanted to be sure). It's only if a website tries to add one of the new actions that they'll need to be sure to wrap with try catch for non-supporting UAs. So there's nothing that will suddenly break by us adding new actions

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

[Yoav Weiss]

As was pointed out at the API owners meeting, 7 likes don't really constitute a strong developer signal. It sounds like you received material feedback from folks that would like to use this API. If that's the case it'd good to post here pointers to those conversations.

That started a discussion on what would be a good signal, and the following scale is where I believe we landed:

* Very low signal - a small number of likes or stars, that can signal a general "I want this", but lacks more concrete feedback or intent.

* Low signal - A large number of such likes.

* Medium signal - Hearsay account of developer intent to use the API once available, with a concrete use case. (e.g. coming from a partner that is reluctant to speak up publicly)

* High signal - Firsthand account of developer intent to use the API once available, with a concrete use case.

There are probably many other forms of signals that fall somewhere in between.

Thomas (and others) - Does that scale make sense?

If so, it may make sense to codify it in the related doc.

 

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

No

Flag name

MediaSessionWebRTC

Tracking bug

https://crbug.com/1178939

Launch bug

https://crbug.com/1174645

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5744304695803904

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/0WrBY77sfh0/m/W60ozzztAwAJ

This intent message was generated by Chrome Platform Status.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwAp3BWNF5KyPQ%3DfBXJRnA_3Gm2sQH5ModT%3DYF5AebKMXqA%40mail.gmail.com.

[Yoav Weiss]

On Thursday, April 8, 2021 at 10:33:14 PM UTC+2 Tommy Steimel wrote:

I want to note that this won't break any existing websites (it's not clear to me if that's what you're implying by "safe to ship new actions" in this context, but I wanted to be sure). It's only if a website tries to add one of the new actions that they'll need to be sure to wrap with try catch for non-supporting UAs. So there's nothing that will suddenly break by us adding new actions

To clarify, the risk from shipping these new actions is not from it breaking existing sites, but from developers that would adopt those new actions without the try/catch clause, causing their site to break in non-supporting browsers.

 

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

[Tommy Steimel]

FWIW, we re