PWA manifest ID property

[Richard Creer]

I'm not sure if this is the right place to post this but here goes.

The PWA manifest id property doesn’t seem to be working, at least not in the way I expected and hoped.

My understanding is that you should be able to have two URLS like this:

https://radixsoftware.co.uk/fruits/orange.html with manifest:
start_url: /fruit/orange.html
scope: /fruit/
id: /fruits/orange.html

https://radixsoftware.co.uk/fruits/banana.html with manifest:
start_url: /fruit/banana.html
scope: /fruit/
id: /fruit/banana.html

The values for id are as recommended by Dev Tools>Application>App manifest>Computed app ID.  Quotation marks omitted for clarity.

Then what I think should happen according to this explainer is that, when the Orange URL reaches the browser and the browser looks at its manifest, it sees id: /fruit/orange.html and says “I don’t know this PWA, let’s ask if they want to install it”.  Later, when the Banana URL reaches the browser and it looks at that manifest, it sees id: /fruit/banana.html and says “I don’t know that PWA either, let’s ask if they want to install it too”.  That way I get two icons on my phone – one for Orange and one for Banana.

What I actually see in Android 10, Chrome 105 is:
The Orange URL installs as a PWA perfectly. Chrome asks if you want to install it and, when you do, you get an icon on your phone and it’s there in your app folder.
However when you submit the Banana URL you are not asked if you want to install it but you can open it the Orange PWA via the Chrome menu.

Am I doing something wrong? Or am I misunderstanding the whole concept? Or is id not implemented correctly in Chrome?

Sample code is available at here with directory browsing enabled.

[Glenn Hartmann]

Hi!

First off, manifest ID support has only been released on desktop so far (Android support is being worked on), so nothing involving the id field is expected to work on Android yet.

Having said that, I believe the behaviour you describe is also what Chrome will do on desktop. The 'scope' attribute of the manifest basically tells the browser that the app 'owns', or can handle, a certain set of URLs. So when you visit the Banana URL after already having installed Orange, there's a bit of an undefined situation, from the spec's point of view.

On one hand, yes, that page does link to a different manifest with a different ID. But on the other hand, the Orange app has already declared that 'fruits/banana.html' is within its scope, and therefore "belongs to" the Orange app. Chrome chooses to respect the Orange app and offer to open the page in the Orange app, rather than offer to install a separate app with the same scope.

In general, having multiple apps with identical or overlapping scopes tends to result in ambiguous situations, and is probably best avoided.

--
You received this message because you are subscribed to the Google Groups "pwa-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pwa-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/pwa-dev/2d687dfe-f3a8-48e9-8e70-ddc7384fd711n%40chromium.org.

[Daniel Murphy]

Here is some more information about why building multiple PWAs on the same origin is not great:

https://web.dev/building-multiple-pwas-on-the-same-domain/#using-separate-origins

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/pwa-dev/CAAfNzYY_LkVumez8fwpLw%3DRWMZX%3DOiU%2BLnr3Z7zGbWU2FRUB%3DA%40mail.gmail.com.

[R Creer (gmail)]

Glenn, Daniel, thank you for your responses even though they are not what I’d hoped for.

 

My mistake, I’d assumed that, when support for ID was announced as scheduled for Android Chrome 96 in the first half of 2022 and observing that I now have Chrome 105 and we are midway through the second half of 2022, support for Id would now be available. But we all know what can happen to IT schedules!

 

But, as you say, Chrome on the desktop behaves as I described. I am somewhat surprised because my understanding of the ID property is that it is intended to uniquely identify a PWA thereby removing any ambiguity so multiple PWAs can exist regardless of their scope, url, path to manifest, whatever.

 

I can’t find any mention of the id property in the article on separate origins so I wonder if the authors were aware of it – their article was published 3 months before the id property announcement. Their ‘challenges’ for same-origin PWAs don’t strike me as being particularly challenging, in fact they could be seen as beneficial.

 

It seems to me that an opportunity is being missed here to show a clear advantage for PWAs. Take the following scenario:

 

1. A SaaS offers virtual noticeboards to sports clubs (or any other organization for that matter).

 

2. A club has a link to its noticeboard on its website.

 

3. A member of the public (MOTP) opens that link and is invited to install the noticeboard as a PWA. So far so good. It’s very easy for him to view that noticeboard.

 

4. Now the MOTP looks at a second club’s noticeboard. In my view he should also be able to install that noticeboard as another PWA. That way he has two icons on his phone, one for each club. Unfortunately as presently implemented this does not appear to be possible. The MOTP must go to the second club’s website, open the link then know to go to the Chrome menu to view the second club’s noticeboard in the first club’s app. Not easy.

 

Incidentally, it is possible to have two PWAs with the same scope on the same device.  Open the Orange URL and accept the invite to install. While it is doing installing open the Banana URL and Add to Phone. Result - two apps installed that work as I would like to see but this is not really a solution for the MOTP!

 

Edge, Opera and Firefox allow separate icons for Orange and Banana to be added to one’s phone. Of course they are not really apps, more shortcuts that open in kiosk mode as far as I can see, but nevertheless they do allow MOTP to achieve that which we wants to achieve.

 

Thanks again

Richard

[Adriana Jara]

Just to add here, you wrote that: "because my understanding of the ID property is that it is intended to uniquely identify a PWA thereby removing any ambiguity so multiple PWAs can exist regardless of their scope, url, path to manifest, whatever."

before `id` (so this is still the case on Android) identifying the PWA was tied to the manifest path or to the value of start_url in the manifest. This are the only two values that can now be changed without the browsers installing a different PWA, See more info here

Scope is different, it is explained in the article that Daniel sent: https://web.dev/building-multiple-pwas-on-the-same-domain/#non-overlapping-paths but using the same origin and specially the same scope is recommended as you can see in the article the browswer just doesn't consider them separate apps. You can read more about the limitations in the article

With Id you can change your start_url and/or scope and the browser will still consider the app the same as before. It doesn't solve the challenges for multiple apps in the same origin. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/pwa-dev/047601d8c78a%24645adbc0%242d109340%24%40gmail.com.

--

Adriana Jara

[R Creer (gmail)]

Adriana, thank you for that. I well understand how it all works but what I am trying to explain is why this architecture is deeply unsatisfactory. I’ll have another go.

 

There is a long tradition of using the same web page to display information about different things – products, places, events, whatever. The classic way of doing this is to append a query string to a URL, eg example.com/?fruit=orange, example.com/?fruit=banana. Users can open individual pages and, if they know how, add them to their phone. That way they get one-tap access to the item of interest.

 

But wouldn’t it be nicer if the web page was installable as a PWA. The manifest can be created on the fly based on the query string and, when the user opens the page, they are asked if they want to install the app rather than needing to know about Add to phone. Plus of course they get an app-like experience.

 

Neat but no! The first instance installs the PWA but the second just opens as a web page. Ok, you can then open it in the app but why would you bother to do that?

 

What’s worse you can’t then Add to phone so, once you’ve got the PWA installed for, say, orange there is no quick way of getting to banana. You have to go and find the original link.

 

What this all means is that PWAs, as implemented by Chrome, are unusable where an organisation wants to use the same code to publish multiple items. And that’s a great shame. Or am I missing something? This is such a fundamental flaw that I feel I must be.

 

Richard