Intent to [Experiment] Origin Trial: Incoming Call Notifications

[Diego Gonzalez]

Spec

The shape of the API and discussions are based on this explainer. Intended to live in the Notifications API spec.

 

Summary

We would like to propose an extension to the Notifications API standard for incoming call scenarios to allow the notification action buttons to be customized and also allow the application to play a ringtone. This capability would make the incoming call notifications, which may require a faster immediate response, clearly distinguishable from the others to the user and would also contribute to increasing accessibility on the Web.

 

Link to “Intent to Prototype” blink-dev discussion

Intent to Prototype

 

Goals for experimentation

Get developer feedback on the effectiveness of the API. Looking for information regarding developer ergonomics, action button scenarios and general overall usage.

 

Experimental timeline

Next availability -> Start M139 until M141

 

Any risks when the experiment finishes?

If there is no `incoming-call` notification scenario, the notification may fallback to `default` and lose its potential “priority” status that could position it above other notifications. The notifications would lose their ringtone as well.

 

Reason this experiment is being extended

First time OT, this is not and extension.

 

Ongoing technical constraints

None

 

Debuggability

As this is an extension to an existing API, there is no expected change in debugging behaviours.

 

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

This OT will be Windows only.

No mobile, no macOS/Linux/CrOS. These will be re-evaluated after the OT.

 

Link to entry on the feature dashboard

https://chromestatus.com/feature/5110990717321216

Diego González

Senior Product Manager

Microsoft Edge

[Domenic Denicola]

I'm curious how this email was generated. It doesn't follow the template created from ChromeStatus, and the non-standard subject line meant it wasn't picked up by the API owners review dashboard.

Anyway, this LGTM, and is approved to experiment from M139 to M141. However, please respond to the following, and correct the ChromeStatus entry as appropriate:

• The ChromeStatus entry says TAG review is not applicable. (The above email is missing this field.) Can you explain why that would be?
• The ChromeStatus entry says there is no interop and compat risk. This seems unlikely, especially given that there are no signals from other vendors?
• The ChromeStatus entry says there is no Finch flag. A Finch flag is required for all new features. Perhaps you confused Finch flag and Flag name on about://flags?
• The ChromeStatus entry has no OT milestones, but this email has them. Please be sure to enter those into ChromeStatus so that it is properly tracked.
• This email contains different answers for debuggability, platform support, and summary versus ChromeStatus. Please ensure these get harmonized. 

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DU4PR83MB077216A4DFAA844FC382E5BECC70A%40DU4PR83MB0772.EURPRD83.prod.outlook.com.

[Diego Gonzalez]

Hola Dominic,

This was generated through a link to a doc in the process documentation. I would actually like to know how does one get to this link you have sent for a feature, as at least as a feature owner for Incoming Calls notifications chromestatus does not provide any indication on where to generate or find the current template for the blink-dev email to go to OT. 

Could I be missing permissions to see this? 

Regards,

Diego González

(PWA PM @ Edge)

---

From: Domenic Denicola <dom...@chromium.org>
Sent: 01 July 2025 04:52
To: Diego Gonzalez <luig...@microsoft.com>
Cc: blink-dev <blin...@chromium.org>; Stanley Hon <sta...@microsoft.com>; Rob Paveza <Rob.P...@microsoft.com>; Limin Zhu (Edge) <li...@microsoft.com>; Ajay Rahatekar <ajayra...@google.com>
Subject: [EXTERNAL] Re: [blink-dev] Intent to [Experiment] Origin Trial: Incoming Call Notifications

 

You don't often get email from dom...@chromium.org. Learn why this is important

[Domenic Denicola]

On Tue, Jul 1, 2025 at 9:56 PM Diego Gonzalez <luig...@microsoft.com> wrote:

Hola Dominic,

This was generated through a link to a doc in the process documentation.

Sorry, I hovered over all the links I could find nearby the section you linked in "process documentation", and wasn't able to find anything linking to that doc. Can you be a bit more specific, so that we can remove all references to this document?

 

I would actually like to know how does one get to this link you have sent for a feature, as at least as a feature owner for Incoming Calls notifications chromestatus does not provide any indication on where to generate or find the current template for the blink-dev email to go to OT. 

Could I be missing permissions to see this? 

The UI is a bit non-obvious. Click "API owners", and then a "Draft Intent to Experiment email" button will appear on the right-hand side. The idea is that it's the same as the other approval processes (Privacy, WP Security, Debuggability).

[Domenic Denicola]

On Wed, Jul 2, 2025 at 10:25 AM Domenic Denicola <dom...@chromium.org> wrote:

On Tue, Jul 1, 2025 at 9:56 PM Diego Gonzalez <luig...@microsoft.com> wrote:

Hola Dominic,

This was generated through a link to a doc in the process documentation.

Sorry, I hovered over all the links I could find nearby the section you linked in "process documentation", and wasn't able to find anything linking to that doc. Can you be a bit more specific, so that we can remove all references to this document?

Ah, this is because Chris already fixed it a few hours ago :) 

[Diego Gonzalez]

Thanks a lot Domenic!

Regards,

Diego González

(PWA PM @ Edge)

---

From: Domenic Denicola <dom...@chromium.org>
Sent: 02 July 2025 02:27
To: Domenic Denicola <dom...@chromium.org>
Cc: Diego Gonzalez <luig...@microsoft.com>; blink-dev <blin...@chromium.org>; Stanley Hon <sta...@microsoft.com>; Rob Paveza <Rob.P...@microsoft.com>; Limin Zhu (Edge) <li...@microsoft.com>; Ajay Rahatekar <ajayra...@google.com>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to [Experiment] Origin Trial: Incoming Call Notifications

 

[Matias Lopez]

Really interested here!

For years we have delimited ourselves to not develop* a native app for just this, incoming call notifications. This API extension addresses a critical gap that has forced many VoIP providers to maintain separate native apps alongside their web applications. The proposed approach is exactly what we need to achieve feature parity.

Technical feedback and suggestions:

1. API naming: Consider using mode or behavior instead of scenario. The current naming suggests "context" rather than "functional behavior", which would be more descriptive for developers understanding the technical impact.
2. PWA-only restriction enhancement: Absolutely agree with limiting capabilities to installed PWAs. However, I'd suggest going further. The API should only allow requesting mode: "incoming-call" notifications if the PWA is actually installed. Non-installed domains shouldn't even be able to attempt creating incoming-call notifications, rather than just falling back to default behavior. This provides clearer developer expectations and stronger abuse prevention.
3. System ringtone approach: Rather than allowing custom ringtones, the API should use the device's configured call ringtone. This maintains consistency with native call behavior, prevents potential abuse (annoying custom sounds), and reduces API complexity while providing the intended user experience.
4. Notification categorization: The proposal should consider how this integrates with platform notification categorization systems. In Android, mode: "incoming-call" should create a separate notification channel that users can control independently (similar to how native apps like LinkedIn categorize "Audio rooms" separately from other notifications). This would allow users to disable regular notifications while keeping incoming call notifications active.
5. DND and Focus mode limitations: There's a significant platform disparity here. Android's notification channels allow granular DND control (users can allow only call interruptions), but iOS lacks this granular control. Users can only allow/deny DND interruptions for entire apps, not specific notification types.

Questions for the experiment:

• Cross-platform timeline: Having a roadmap for macOS/Linux/Android would help us plan our development strategy beyond the Windows-only OT.

The examples perfectly match our requirements. Being able to differentiate call notifications visually and audibly while maintaining the web platform's security model through PWA requirements is exactly what the ecosystem needs.

We'd be very interested in participating in testing during M139-M141. This could finally enable us to sunset the idea of native app.

* We provide a fully web app to B2B enterprise customers, any kind of native installation requires a lot of investment for us to audit it, just for incoming call notifications.