Intent to Experiment: Badging API V2

[Matt Giuca]

Contact emails

mgi...@chromium.org, ray...@chromium.org, harr...@chromium.org

Spec

Explainer: https://github.com/WICG/badging/blob/master/explainer.md#detailed-api-proposal (up to date)

Draft: https://wicg.github.io/badging (obsolete)

Summary

Allows websites to set a badge applying to a URL scope, shown in a user-agent-specific place. In our experiment, we badge installed web applications (as defined by the Web App Manifest standard) on the operating system shelf. The badge can optionally show a positive integer over the top of the application icon.

Badge API was the subject of a previous experiment from M73 to 77 (https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/KEUnHsvulEU/tMzKbzHxBQAJ). That version was not URL-scoped and was specifically tied to installable apps. The feedback received from that experiment indicated that we should generalize the API to not just apply to installed apps, and that sites need to be able to apply badges to URL scopes for control over which apps / pages the badge appears on. The new experiment adds a new "scope" parameter to the API which we want to get feedback on.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/Fw764MVF5nI/FNlBi815AwAJ

Goals for experimentation

We want to focus specifically on the changes to the API, specifically the addition of the "scope" parameter and the new complexity of setting badges at certain scopes and clearing them (which can cause the badge to fall back to one set in an outer scope).

Some questions:

• What should be the default scope if none is supplied? (Currently, "/")
• General feedback about the introduction of the "scope" parameter, and the complexity of adding nested scopes. (Note: We don't need nested scopes; it would be easier without them, but this is the only way we have thought of to allow different apps on the same origin to be badged independently.)
• Should the set and clear methods be renamed to allow for a future document-scoped version of the API, as discussed in https://github.com/WICG/badging/blob/master/explainer.md#a-case-for-separation?
• Is the current path-based scope sufficient (is there a need for "handle" type badges to apply to certain query parameters, etc)?

Experimental timeline

• M78: Experiment begins.

• M80: Last milestone of the experiment.

• M81: Planned general availability of the API.

We plan to make necessary changes to the API during the experiment.

Any risks when the experiment finishes?

No risk of data loss. However, it would represent a disappearing prominent feature in apps using it.

The planned transition from experiment to general availability (assuming the API is not outright rejected) ensures that early adopters do not have to have the feature removed for any time. Thus the only risk here is if we decide not to proceed with this API at all.

Ongoing technical constraints

There is some technical complexity here due to having a separate implementation of the API on each of the supported platforms (at the time of writing, Chrome OS, Windows and macOS).

Debuggability

N/A

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

Only Chrome OS, Windows and macOS (with a separate implementation on each, to talk to each platform’s internal API for badging). On Chrome OS, we are working with the Shelf team to plug into the implementation that is being built in parallel for Android apps to show a badge.

• Linux is not being initially supported. There is no general API (that I know of) for all Linux window managers. Ubuntu has one specifically for its window managers, which we could support in the future.

• Android has no API for setting a badge. The Badge UI seen on Android is automatic when an app sends a notification, and is not individually controllable by apps.

See this document for details on how we plan to interface with each OS (keeping in mind that on Windows, we use the Win32 API, not the UWP one, both for compat with Windows 7, and because we don’t think we have access to the UWP API).

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6068482055602176

[Chris Harrelson]

LGTM

--
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/CAHqYdcbrtGB5A9pPitPPyB0NQn8MQ4n51bcAOLJWPSw_aetCGw%40mail.gmail.com.

[Matt Giuca]

Hi blink-dev,

We had some discussions about this API at W3C TPAC conference last week and as a result of these discussions, we'd like to change tack on this.

We had already implemented the changes to the API for the M78 branch, including changing to a new feature name ("BadgingV2") requiring a new set origin trial tokens. However, the discussions at TPAC led the API design in a different direction, in fact much closer to the original API that already went through the OT process, as proposed here:

https://github.com/WICG/badging/issues/55

As a result, we think it would be a mistake to ship M78 as-is, because it would be presenting a new Badge API for one milestone, then essentially revert back to the old one. We'd like to make the following changes in M78 beta (https://crbug.com/1006665):

1. Land and merge a change to revert the API back to the old (non-scope) behaviour. We can't just revert the change (https://crrev.com/692412); that is a +775 -373 line diff that already has dependent patches. Instead, we would produce a small (~30-line) patch that disables the scope parameter and restores the old defaults (the default scope would now be the most specific app, rather than the origin), and merge it.
2. Revert https://crrev.com/693555, the CL that changes the feature name from "Badging" to "BadgingV2", and merge it. This is because it doesn't make sense to ask developers to sign up for a totally new origin trial that will be exactly the same as the previous one.
3. Request an extension of the Badging V1 origin trial for one additional milestone (M78), so that the feature doesn't disappear during this time frame.

In terms of the Chrome release process, we would consider this to be a regression: although not an accidental bug regression, it has the same characteristics, which is that if we didn't make these merges, the behaviour would change for one milestone, then change back, which would be undesirable for our users.

For M79, we will make the changes decided at TPAC, and move into the BadgingV2 origin trial.

Are there any objections to us proceeding with this plan? Please follow https://crbug.com/1006665 for updates.

[Chris Harrelson]

Hi Matt,

Thanks for the clear explanation of the change you'd like to make. I think this all sounds fine. Glad to hear there was useful discussion at TPAC and movement towards consensus!

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