Add API to retrieve document's computed manifest

[dmurph]

Devs want to be able to fetch the document's current manifest state, and possible get other metadata, for production code & testing.

Some possible ideas:

let manifest;
try {
 manifest = await document.getManifest();
} catch (e) {
  // handle network error, parsing error, etc.
}
console.log(manifest.id);
// Is metadata needed?
let metadata = manifest.getMetadata();
// The manifest is always populated with defaults
console.log(metadata.isDefaultManifest);

or maybe

let data;
try {
  data = await document.getManifest();
} catch (e) {
   // handle network error, parsing error, etc.
}
let manifest = data.manifest;
console.log(manifest.id);
let metadata = data.metadata;
let isDefault = metadata.isDefault;

or maybe

let manifest;
try {
  manifest = await document.getManifest({excludeDefaultManifest: true});
} catch (e) {
     // handle network error, parsing error, etc.
}
if (manifest != null) {
  console.log(manifest.id);
}

[marraui]

+1

Currently if we have two PWA's pointing to different urls, but on of the urls ends up redirecting to the other one, there is no way to distinguish between the two versions of the app.

[marcoscaceres]

@marraui, can you clarify a bit more? In theory, scope would prevent that from ever happening. Can you help us understand this a bit more?

[dmurph]

Do you want the manifest of the app window you're in? Or the document?

like - window.getManifest() vs document.getManifest() - I'm guessing the window one maybe should be only possible to see if the url is in-scope of the app? Or on the same origin?

[dmurph]

I could imagine this would be useful if, say, you had a javascript library that was used in both places. If that library needed to know which app it was in, it could fetch the manifest and see the id, etc. Is that your case?

[marcoscaceres]

the only case I can think of is:

• APP 1 - example.com scope: "/"
• APP 2 - example.com scope: "/foo"

There the identity would help to know if you are APP1 if it goes into "/foo".

[marcoscaceres]

Could we consider attaching the computed manifest to the <link>, as it's the one loading the manifest?

[mkruisselbrink]

Having this feature would also enable writing web platform tests for at least the manifest processing parts of features that otherwise don't have much in the way of web exposed behavior.