Accurate exposure of Notification properties

[Peter Beverloo]

Since Web Notifications expose system-level functionality to websites, one of our goals is to enable developers to provide a high-fidelity experience regardless of the user's choice of platform.

While we try to offer consistent support wherever possible, there are a number of cross-platform inconsistencies as well. To name some examples:

    - Notification.`vibrate` is only supported on Android.

    - Notification.`badge` (née small icon) can only be supported on Android Marshmallow+.

    - Notification.`requireInteraction` is only applicable for the desktop platforms.

Right now we expose all properties on all platforms, which breaks feature detection. Ideally a website would be able to determine whether badges are supported by checking ('badge' in Notification.prototype).

For upcoming features such as inline replies and big picture notifications, this would further enable them to provide an alternative if it's not available on the user's browser or platform. (Creating a notification is unaffected in either case— this is done through a dictionary that just ignores unknown values.)

Suppose that we only expose what's actually supported by the platform. This raises two questions:

    (1) Are we concerned about compat issues? Since (a) it's uncommon for websites to read back the notification properties, and (b) cross-browser notification support is inconsistent as-is, I'm not particularly concerned myself. This would need an UMA & an Intent to Unship regardless.

    (2) We'd need a series of [RuntimeEnabled] annotations for these properties, and this would derive from the current RuntimeEnabledFeatures.in policy. Intuitively runtime_features.cc still feels like the right place to set the values, which also implies more plumbing through the Blink API.

Any other thoughts or concerns about this approach?

Thanks,

Peter

[Ian Clelland]

I like this; I think it's the right approach. Feature detection of exposed interfaces *should* be the web's system for smoothing out compatibility issues between platforms.

RuntimeEnabled also feels like the right spot, where the default values can just be set differently per-platform. (I expect that I can probably tie this work into the Unified Features proposal[1] as well, so it may not end up being called 'runtime enabled' in the end, but the mechanics would still work as you'd expect.)

[1] https://docs.google.com/document/d/1PHkCEyfUKwhoJEiRwcio9JWU5xQ1OuvIRb8enSbfYxY/edit?usp=sharing

[Rick Byers]

I think I like this idea, but this is probably more of a standards discussion than a blink implementation discussion.

A counter-example to this type of approach is input hardware.  We've explicitly said that what input APIs are supported should be distinct from what devices happen to currently be present (eg. TouchEvent.radiusX/radiusY default to 0, PointerEvent has tiltX/tiltY even for input devices that don't support tilt, DeviceOrientationEvent exists even on desktops without accelerometer hardware).  Then we have a separate API (InputDeviceCapabilities) for querying properties of specific devices.  A big part of the reason for this design, of course, is that (even previously unknown) input devices can come and go during the life of a page - we don't want the API surface area to change over time.  Of course we still have a long standing bug (for web compat reasons) that the TouchEvent API is only enabled by default when we see a touch screen :-(.

Also, it's worth thinking through the implications for mobile emulation in DevTools.  Developers do tend to do a lot of their development/testing in DevTools rather than on real devices, but presumably that's already not really good enough when it comes to notifications?

[Jochen Eisinger]

How would a website detect whether a certain feature of site input device is present or not?

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAFUtAY_SSLuX9iNXQQhxeiRtsdTtiMGNihEh%2BL_-j_QB%2B2O7jA%40mail.gmail.com.

[Elliott Sprehn]

Note that the more dynamic the system is that constructs our interfaces the slower it is. In general I don't think we want to do this for very many things on the web, we need context creation to be much faster and as close to a memcpy as possible. I still see iframes take 10ms to create on a 5X which means you have no hope of avoiding jank on the main thread. Until we make that just a few ms I think we should be very careful where we apply this kind of runtime feature enabling. It'd be pretty sad if we made that 10ms into 11ms...

- E

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAK_TSXKC%3Dm-nns642YpHCDvOuAk3Lv0BNhMcWgn1iP5-bTXHVg%40mail.gmail.com.