Shortcut item should have an "id" field

[mgiuca]

This is kind of similar to how we just added the "id" field; it's a small scale version of the same problem.

Problem: There isn't a stable identifier for shortcuts. That means if the user agent wants to associate any persistent information with a shortcut, with a lifetime that persists across manifest updates, there is no way to properly know in the new manifest, which shortcut corresponds to a shortcut from the old manifest.

Two concrete use cases:

• User drags a shortcut from the app context menu to the home screen (this is already possible on Chrome for Android, and I'm not sure how they've dealt with this problem).
• The user agent wants to associate info with a shortcut, for example, how many times the user has used that shortcut, in order to rank it in a search results page.

What if the manifest updates, and the shortcut's user-facing string name, icon and/or URL changes? How does the user agent retain the information associated with the shortcut, and know which shortcut in the new manifest it corresponds to?

(More directly: what member of shortcut item should the user agent use as the primary key in the database for the above two use cases?)

Currently, the most likely candidate for a primary key is either the name or the URL. But both of those can plausibly change while the underlying semantics of that shortcut remain the same.

Proposal: Like with the app ID, we need an explicit field to serve as a stable identifier for a shortcut item. This field would be a user-unfriendly string (never seen by the user), which is expected never to change across manifest versions, even if the name, URL and other metadata changes. It would be considered to uniquely identify the shortcut within this particular app (so the tuple of (app-id, shortcut-id) globally uniquely identifies the shortcut). Its default value could be the name or URL, or just say if unsupplied then it's up to the user agent.

TODO: What does Chrome for Android do here? Note that you can install the Twitter PWA on Android, long-press its icon, drag "New Tweet" to the home screen, and have a persistent button to open that shortcut. What happens if Twitter changes the name or URL associated with that shortcut?

[mgiuca]

@jeevan-shikaram who proposed this.

@loubrett who also suggested an alternative (non-temporal) use for shortcut IDs : translations for shortcuts currently need to be carefully lined up 1-to-1 (the array elements in the base manifest and translation manifest need to exactly correspond). If shortcuts had IDs, we could match them up based on ID rather than array index.

@aarongustafson who added shortcuts, and incidentally is working on translations. @dmurph, @philloooo who worked on app IDs. Does this sound like a reasonable step along the same lines?

I'm thinking this is really simple compared to app IDs: just add one new member called "id" and say roughly the above. No need to define any logic in the spec on it. Just say that user agents can use that to identify shortcuts across different versions of a manifest.

[dominickng]

Regarding dragging shortcuts on Android, my guess is that the action simply creates a view intent to the URL in the shortcut. This is akin to creating a .lnk shortcut on the Windows desktop passing specific arguments to an executable. These would not update if the app changed its internal URLs as the app has no idea the shortcut exists.

[mgiuca]

Ahh good point Dom, you're probably right. So there would simply be no update at all.

That's probably undesired behaviour though, though a much bigger project to fix than simply defining IDs.

[alancutter]

We should use the URL as the default ID value for mild consistency with the manifest ID defaulting to start_url.

[songql]

It's support the shortcuts since Android 7.1(API 25), the shortcut on android means excute an intent.
Intent is a feature in Android development, it carries various operations in the android program.

ref:
ShortcutManager
Create shortcuts
Intent

[mgiuca]

@alancutter It was with some trepidation that I suggested the default be a URL, given the discussions we had around the app ID being a URL (justified since the default was the start_url).

I find myself a bit less keen to make this one be a URL, given that it's already qualified by the app ID. (It means that if the shortcut ID is a full URL, then the fully qualified shortcut ID is ('https://example.com/app_id', 'https://example.com/shortcut_action_url') which seems fairly redundant and unwieldy. But it works I guess.

[alancutter]

I would be surprised if the fully qualified ID was ever written by site developers. The only scenario that would happen is if someone needed to reference a third party web app shortcut.

[dmurph]

I'm a fan of this. I instinctually have the preference of the URL being the default id here - but I don't know if I have any good reasons for this. Somehow it seems less fragile than the name? But perhaps name is better?

[jeevan-shikaram]

I think that using the name or URL as the ID could lead to issues when a developer wants to change either of those.

For example, a shortcut to upload an image has the name "Upload image" and URL example.com/upload/image. The developer updates their site to accept video files and would like to update the shortcut to have the name "Upload media" and the URL example.com/upload/media.

If we use the name or the URL as the ID, it could cause issues mentioned in the post above. I think a standalone ID field would work best.

[dmurph]

the question here is "What is the field's default if it is not specified?"

[songql]

As a web app or web site, different urls provide different function. It's not the same function if the developer change the url. The developer should redirect to the new url for compatibility if you it's means same or function upgrade.

And I agree with the point of @alancutter :

I would be surprised if the fully qualified ID was ever written by site developers.

[mgiuca]

@songql Are you suggesting that we don't need this proposed feature, because the action URLs should be stable, and therefore we should use the URL as the primary key?

That makes some degree of sense, after all, if the user bookmarked a URL then they should expect it to work in perpetuity, so why should shortcuts be different? But this is somewhat different because if you change your URL (and let the old one redirect to it), you should be able to update your manifest to point to the new URL. And if you do that, you risk user agents breaking the existing shortcuts. So you're kinda stuck being unable to change the canonical URL of your shortcut.

[songql]

@mgiuca I agree that the situation mentioned in your proposal exist and need to be resolved. It's just that I don't think it is particularly suitable for assigning ID attributes to shortcuts.
I think this situation should not use browser favorite links or desktop url shortcuts, but a new mode to support web applications provide services to others.
In the above reply, I put a few Android-related links. I think it would be a new idea to refer to Android’s Intent to give web applications more capabilities to solve such issue, not just limited to the current mode.

[aarongustafson]

@mgiuca I apologize for being late to the game here.

I’m definitely in favor of allowing for an explicit id (or similar) field. In translations we’d talked about using order as the mechanism for providing the overrides, but I feel like that could become problematic over time. Also, having an author-provided id would unblock the dynamic shortcuts work, which is currently in a holding pattern, as it would enable a dev to target a specific manifest-defined shortcut and tweak it dynamically (for instance, appending the current song name to a "now playing" shortcut).

When the id is not specified, I think the URL-driven tuple probably makes sense, but I’m guessing we’ll hit the occasional snag if folks include (and change) query string params or if their URL structure changes over time. We should probably call that out in the spec as a note at least and push people to update their manifest with explicit shortcut IDs prior to migrating shortcut paths.

[alancutter]

Also, having an author-provided id would unblock the dynamic shortcuts work, which is currently in a holding pattern

Oh nice! Do you have a rough idea of what that API surface could look like? I'm quite interested in the data persistence model.

[dmurph]

Notes from editor meeting:

id seems like it would be helpful & unblocks functionality outlined above. But it doesn't look like this functionality is actually implemented in any platform.

Another idea is to have the 'default' id just be the array index, so if this feature was ever needed and an update was happening, then the developer could add ids corresponding to the old array indexes.

There are enough proposals here for the default id that it seems like this could easily be added in the future if any of the features above were added to a platform. So we can defer until the time this feature is requested.