Glad to see this origin trial. CCing +fugu-dev <fugu-...@chromium.org> +pwa-...@chromium.org <pwa-...@chromium.org>
On Mon, Jul 7, 2025 at 7:12 AM 'Matias Lopez' via blink-dev < blink-dev@chromium.org> wrote: > *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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c3cd3e08-5fff-4915-9154-b92eb7ccad0bn%40chromium.org?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/CAK-EfX%3DpDY7TLgVQgPeZcXnfOYX9-XWxZ8TvifOab-1PdMfGXw%40mail.gmail.com.
