*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.
El miércoles, 2 de julio de 2025 a la(s) 4:24:02 a.m. UTC-4, Diego Gonzalez
escribió:
>
>
> 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
>
> You don't often get email from dom...@chromium.org. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
>
> 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
> <https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit?tab=t.0#bookmark=id.pygli2e122ic>
> in
> the process documentation
> <https://www.chromium.org/blink/launching-features/#origin-trials>.
>
>
> 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
> <https://chromium-review.googlesource.com/c/website/+/6697273> a few
> hours ago :)
>
>
>
> I would actually like to know how does one get to this link
> <https://chromestatus.com/feature/5110990717321216/gate/5269432429969408/intent>
> 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).
>
>
>
>
>
>
>
> *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 <https://aka.ms/LearnAboutSenderIdentification>
> I'm curious how this email was generated. It doesn't follow the template
> created
> from ChromeStatus
> <https://chromestatus.com/feature/5110990717321216/gate/5269432429969408/intent>,
>
> 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.
>
>
> On Tue, Jun 17, 2025 at 5:55 AM 'Diego Gonzalez' via blink-dev <
> blin...@chromium.org> wrote:
>
> *Spec*
> The shape of the API and discussions are based on *this explainer
> <https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Notifications/notifications_actions_customization.md>*.
>
> Intended to live in the *Notifications API
> <https://notifications.spec.whatwg.org/>* spec.
>
> *Summary*
> We would like to propose an extension to the *Notifications API
> <https://notifications.spec.whatwg.org/>* 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
> <https://groups.google.com/a/chromium.org/g/blink-dev/c/PtHemJah2Qc/m/gsrgJW9LCAAJ>*
>
> *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
> <https://chromestatus.com/feature/5110990717321216>*
>
>
>
> *Diego González*
> Senior Product Manager
> *Microsoft Edge*
>
> --
> 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
>
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DU4PR83MB077216A4DFAA844FC382E5BECC70A%40DU4PR83MB0772.EURPRD83.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3cd3e08-5fff-4915-9154-b92eb7ccad0bn%40chromium.org.
