Web Manifest 2

26 October 2020


Aaron Gustanson, aarongu, Alex Russell, anssik, Christian Liebel, Christian_Lieber, christianliebel, dmurph, Kenneth_Christiansen, krosylight, Marcos_Caceres, marcosc, slightlyoff, Thomas_Steiner, Tiger Oakes, tomayac
marcosc, slightlyoff, tomayac

Meeting minutes

Agenda bashing

CL: we could talk about these tests https://‌github.com/‌web-platform-tests/‌wpt/‌pull/‌24452

AK: do we have good apple contact as they are the second implementation?

AK: what's mozilla status?

<tomayac> WebKit's status is "partially supported" https://‌webkit.org/‌status/#specification-web-app-manifest

MC: On the Mozilla side, I'm still maintaining the implementation. But probably need to find someone else to take over at some point.

MC: we have people like hober and Maciej that we can ping... but I'm unsure who is best contact there

TS: Icon support is still lacking on the webkit side ...

MC: Not sure what their plans are with regards to icons. However, icons are supported on the Gecko side along with Blink.

<tomayac> scribenick tomayac

<tomayac> MC: Calling for agenda topics

<kenchris> +present Kenneth_Christiansen

<tomayac> AK: MIlestones up-to-date?

<anssik> Present https://‌github.com/‌w3c/‌manifest/‌milestone/‌1

<tomayac> ...Been looking at Christian's milestones chart, is it still updated?

<tomayac> CL: Almost, just one issue

<tomayac> ...that doesn't have a label

<tomayac> ...Only the latest issue would have to be triaged

<christianliebel> https://‌github.com/‌w3c/‌manifest/‌issues/‌934

<tomayac> ...We should add issue 934 to the milestones, or decide if we want to

<tomayac> MC: Yes

<tomayac> MC: I see Matt also reviewed it

<tomayac> MC: Alright, issues are up-to-date

<tomayac> CL: We could have a look at the testing topic, around shortcuts

<tomayac> ...Which is the only pending test.


<christianliebel> https://‌github.com/‌web-platform-tests/‌wpt/‌pull/‌24452

Shorcuts tests

<tomayac> MC: Let's switch topics to testing

MC: Tests are looking good. The only comment I had was: right now we're defaulting the URL to the manifest

<marcosc> i.e., we have url: ""

<marcosc> https://‌github.com/‌web-platform-tests/‌wpt/‌pull/‌24452/‌files#r467212849

CL: Another discussion is around (pasted link)

MC: Whether having an empty URL for "url" was a bug or a developer issue.

<marcosc> "shortcuts": [{"url": "",}]

MC: For example (pasted code)

MC: IMHO it's not a bug
… Basically just a developer error. An impl can warn.
… But don't think. we should do more about it

CL: So resolve the convo

MC: Christian, are you OK to add the missing files?

CL: Yes
… Can bring back the test

MC: An interesting problem that arises from shortcuts and other deep links is what happens if an app is showing and you go to one of the shortcuts.
… What happens to the history of the app itself?
… I'm droppping a link
… imagine you launch an app, navigate around. Then you minimize the app. Then in Windows you pick a shortcut.

KC: On Windows it starts another instance
… That's Windows, not sure about others.

MC: Any time you click a shortcut?

KC: That's why we have the launch event that could intervene

<marcosc> Related issue https://‌github.com/‌whatwg/‌html/‌pull/‌6085

KC: I sometimes open Twitter in a separate tab for quick one-offs

MC: This came up in HTML for navigator

MC: Is this supported in Chrome OS?

KC: On Android it's implemented

KC: (Tries what happens on Android)
… On Android it replaces the running instance
… I lost my state

TS: Isn't this what native apps do?

KC: (Tries what happens on Google Maps)

KC: This is what happens on native apps

TS: Mostly is not confusing. People don't assume several instances for an app

KC: It's annoying since it replaces whatever users were doing

MC: (Also trying)

MC: You tried with Maps?

KC: Yes, with Maps

KC: The same with Twitter

MC: I wonder why? I agree that it's annoying

TS: Isn't this just apps handling state badly? They should warn when state would be lost.

CL: Agree

MC: It just kills the other app and launches a new one
… testing a native app with shortcuts
… Let me triple check

MC: Closes and does a complete replace
… Don't have a strong opinion

TS: My opinion would be to reflect what the platform does

CL: Would expect Windows to replace the instance

TS: We should confirm with Microsoft that launching a new instance is intended

MC: Let me confirm with Aaron tomorrow

MC: On Windows it opens a new browser instance, on Android it kills the running app and restarts (causing a complete replace)
… Seems to follow OS conventions

<marcosc> https://‌github.com/‌whatwg/‌html/‌pull/‌6085#issuecomment-716337809

<marcosc> MC: comments I made over at the HTML spec

MC: Just putting in a comment over at the HTML spec

MC: OK, that addresses both the test and the feature per se as it relates to deep links

General moving forward

MC: Let's have a look again at the milestones

<marcosc> https://‌github.com/‌w3c/‌manifest/‌milestone/‌1

<marcosc> "Support a way to update explicitly"

MC: Kenneth have you had a chance to support update?

<marcosc> https://‌github.com/‌w3c/‌manifest/‌issues/‌446

KC: Not yet

MC: Are there user interventions?

TS: Here's what Chrome does: https://‌web.dev/‌manifest-updates/
… Nothing standardized quite yet, but since Marcos was calling for behavior documentation

MC: Added that link to the issue 446

<marcosc> https://‌github.com/‌w3c/‌manifest/‌issues/‌446#issuecomment-716340037

MC: That's enough for now, thanks to Tom, side thanks to Pete

MC: Is there anything that anyone is itching to work on?

KC: No

CL: Tasks 380, examples of scope
… Was waiting for some PR to land
… Did we decide on the scope thing? Forgot the exact history

<christianliebel> https://‌github.com/‌w3c/‌manifest/‌issues/‌380

CL: This is my issue, not sure whtat's blocking it now

<christianliebel> https://‌github.com/‌w3c/‌manifest/‌pull/‌880

CL: I think it's the (pasted link) PR

AK: There's another web.dev article https://‌web.dev/‌add-manifest/#scope

MC: We were close to finishing this…

CL: Also open to resume weekly calls or take on other issues

MC: The discussion is a wall of text
… Christian brought this up. Should we resume the working sessions

MC: I would also agree

MC: Not sure how much you got out of this, Kenneth

KC: The first ones were good

AK: If we focus on issue, pre-triage and then we can prepare

MC: Agree. If we need specific expertise, we should do it that way

KC: Same issue as Anssi, always takes time to warm up and get context

AK: If you think others point of views could help, let us know
… Then we can have a short chat, very focused

MC: Don't have many of those, but that's a good problem to have

MC: Hoping to re-engage with the spec, starting this week. Will drag people in as needed

MC: Given we had the lapse in working on this, we have all lost track a bit
… That's fair, we can catch up

CL: Exact same thing. Was the same status already back in May

KC: For something that's a living standard that's good

AK: Do we have a ton of feature requests?

MC: Yes

<marcosc> https://‌github.com/‌w3c/‌manifest/‌issues?q=is%3Aissue+is%3Aopen+label%3A%22Feature+Request%22

<marcosc> Feature Requests ^^^

AK: Do we have a plan?

MC: Right now the plan is to defer all feature requests until we can proceed the spec to CR
… Not taking any new features
… Unless they are of siginificant prio to implementors

AK: Is it fair to say Chrome/Google implement, and then sometimes Apple follows?

MC: Yes and no, mostly no. Hopeful Apple folks will continue to talk to us
… about the things they plan to support

TS: Who was the Apple contact?

MC: No one really

AK: The second implementor doesn't make a contact available

AK: Who is the more likely 2nd implementor?

MC: Mozilla

AK: OK, happy to have Mozilla then

MC: I'm pushing Mozilla's impl forward

AK: Do you have funding?

MC: No funding, but it's my impl, it's an easy spec

AK: Are you looking for funding?

MC: I like my independence

AK: Just asking?

MC: Not a big deal really, it's simple enough, I wrote the code and know it

MC: No compiling involved

MC: We will use Firefox as the second impl, having Safari as the 3rd impl is also good. Safari adheres pretty closely.
… Impl is open source and we can fix things

KC: Not icons, though

AK: Has Igalia been doing any manifest work?

MC: No

AK: You can throw money at Igalia

MC: Let's wrap this up

<christianliebel> https://‌github.com/‌w3c/‌manifest/‌issues/‌905

CL: Quick question
… It's about the monochrome purpose

<marcosc> Related chrome bug https://‌bugs.chromium.org/‌p/‌chromium/‌issues/‌detail?id=1096388

TS: The Chrome bug is marked fix, Matt was the reported, glenrob@chromium the owner

TS: Matt is our contact

CL: Judging from the description, it seems to be a simple rename
… Question would be: is this actually implemented?

MC: Looks like this landed?

TS: Can someone fill in the context?

CL: For notifications before you had the badge icon, so we decided to intro monochrome where you have different color reqs, so it's basically a new name

TS: Let's ping Matt on the GitHub thread

CL: Sure

CL: I do it

<marcosc> "Renamed Manifest::Purpose::BADGE to MONOCHROME to match the spec."

TS: According to the first comment in the bug, monochrome just is there, but doesn't do anything

TS: Why monochrome, and no colors? System req?

MC: Changes to monochrome, so it could be re-colored
… and used generically

MC: And I think even Safari uses something related

TS: Yes, there is something for the touch bar on Macs

MC: It's in a similar vein

MC: Any other topics?


<dmurph> +p


<marcosc> * "Add a unique identifier for a PWA" - https://‌github.com/‌w3c/‌manifest/‌issues/‌586

<marcosc> * "Adding field `display_override` to the manifest" - https://‌github.com/‌w3c/‌manifest/‌pull/‌932

<aarongu> here+

Add a unique identifier for a PWA

<marcosc> https://‌github.com/‌w3c/‌manifest/‌issues/‌586

dmurph: I can give an overview...added it to the agenda before some of the end of the bug's discussion, but to summarize, "what is a web app?", "how do we uniquely identify a webapp?". Need to solve htis for associated issues: udpates, reviews, etc.

dmurph: currently done 2 different ways in Chromium. On mobile, it's tied to manifest URL. Nice, but you have to have a URL to be a webapp. Some folks have a goal of "let's just have the manifest by itself uniquely identify a site"...well, manifest + origin. Some efforts to decouple the manifest from the document URL...one thing still tying the webapp to something else...

dmurph: desktop does this differently; uses the `start_url`. Downside: if a manifest updates the `start_url`, silently breaks the app. Icons now fail to update, etc.

dmurph: so ew're already in a bad state, but how do we get to a state where they're standardised?

aarongu: is it disregarding query string in the `start_url` case?

dmurph: don't know

dmurph: we'd need to test. Using a hash of the `start_url` internally.

dmurph: summary of the thread is origin + full manifest URL

dmurph: there's no restriction on having a webapp manifest being on the same origin as the webapp. E.g., `https://‌example.com/‌manifest.json` can be pointed to by `https://‌b.com/`

aarongu: we were trying to resolve that because we were wondering if 3rd parties should be able to install

aarongu: there's a discussion tomorrow about triggering install from a 3rd party....so a PWA app store could trigger an install....kind of related

aarongu: if I understand correctly, want to create an association of a PWA with a storefront?

dmurph: and updates

aarongu: one of the things I've been looking at (no explainer yet) is the ratings and reviews piece; looking at tying to he `related_applications` entries unique identifiers

aarongu: maybe that's a way to resolve it in the context of app stores?

dmurph: haven't thought about how this related to app stores

dmurph: origin + identifier (manifest URL or start_url)

dmurph: my proposal was `start_url` but have it be overridable by the developer...we simplified down to manifest URL

dmurph: ben francis mentioned that it was manifest url

tiger: mozilla uses `start_url` on mobile

dmurph: we're going to need an escape hatch somehow...a field for "override my unique identifier URL"

aarongu: or for instance if your URL changes

(changing domains/ownership, e.g.(

dmurph: for this we were explicitly not considering an origin change in the scope of this bug

<dmurph> there are also first party origin sets

slightlyoff: when we originally designing this, I'd suggested SW scope + manifest URL, so happy to see origin + manifest URL

<discussion of origin + identifier>

dmurph: thoughts on manifest URL vs. `start_url`?

aarongu: based on the query-string issue w/ `start_url`, I'd prefer manifest_url

slightlyoff: I suspect we'll have some behaviors that won't work w/ query params across cache claering, both manifest URL and start_url

aarongu: we use query params on manifests to do language differentiation

aarongu: we are going to look into this to see if fingerprinting is happenign at scale

dmurph: are we happy to couple to manifest URL?

slightlyoff: we could perhaps solve the hermetic issue in Web Bundles? Is there a situation that isn't addressed that way?

dmurph: perhaps the problems related to CDN hosting of manifests?

marcosc: looking at the history here...we haven't worked out the update mechanism and how it relates back to this

marcosc: when we originally designed, thought some impl detail would identify things...wouldn't be developer visible

marcosc: the use-case of storefronts...how do I surface these apps. Right now, need to solve the update mechanism

marcosc: looking at the implementations for install time, an implementation detail across all engines?

marcosc: by settling on something...needs to be in the spec?

slightlyoff: proposed resolutions: can we summarize, put in non-normative manifest spec text? And if taht's not palletable, write up as a separate incubation/doc? Important to have it written down

marcosc: sounds ok; dmurph can you write this up?

dmurph: yes

Action: dmurph to write up conclusion from this discussion for inclusion

<NotWoods> Android code: https://‌github.com/‌mozilla-mobile/‌android-components/‌blob/‌master/‌components/‌feature/‌pwa/‌src/‌main/‌java/‌mozilla/‌components/‌feature/‌pwa/‌db/‌ManifestEntity.kt

marcosc: how does this work on Firefox for Android?

NotWoods: this is in a SQL db...can be migrated. Older identifiers could be detected and handled differently

NotWoods: a wrapper around the manifest could determine what these are

dmurph: migration in Chromium is likely to be complex

marcosc: likely as far as we can go on this issue; final thoughts?

dmurph: final thought: do we know what Safari does? Maybe we can add an identifier field before we have to do a big migration?

<marcosc> slightlyoff: we could use the service worker's scope URL in conjunction with the start URL, where the start URL must be in-scope of the service worker scope.

slightlyoff: `start_url` doesn't seem as clearly to identify the app's "identiy" as the manifest URL (SW scope + manifest were my old proposal)

<discussion of browsers that don't require SW registrations>

marcosc / slightlyoff: <back and forth on SW scope and origin relationship>

Adding field `display_override` to the manifest

dmurph: I have enough to go on

<marcosc> https://‌github.com/‌w3c/‌manifest/‌pull/‌932

dmurph: quick overview: simplest way to understand the problem: if a site wants `minimal-ui`, only compatible w/ developers that support it.

dmurph: we have a hard-coded fallback chain today

dmurph: fullscreen -> standalone -> minimal -> browser is strict

dmurph: what about sites/browsers that don't overlap this way? e.g., site that would want to be `minimal-ui` if available, but browser if not, but still installable?

dmurph: want to let developers have control over their preferred fallback order

dmurph: this unlocks future explorations for display; e,g. tabs and control overlay. Unclear where to put these in the fallback list

dmurph: standalone and minimal relationship to tabs? Hard to make a single call. Adds flexibility to better support those additions. More ideas around "create your own display mode" for allowing more optionality around features. Starting with custom fallback list.

aarongu: had the same question...marked resolve, but matt brought up the example of fallback order

aarongu: how to handle situations where browsrers don't support `display_override`? Missing from the PR

<discussion of how to handle a missing example in the PR>

dmurph: will handle it; can you re-open the discussion?

dmurph: blocked on getting feedback from others. Signals from Mozilla and Apple would be helpful. What aren't we seeing? What should be done differently?

marcosc: krosylight, I know you're just observing, but perhaps you can figure out who can look at this from Mozilla?

krosylight: I can try to poke at someone who can look at this

<marcosc> https://‌github.com/‌mozilla/‌standards-positions/‌issues/‌447

marcosc: was a Standards Position filed on Mozilla?

<yes, #447>

NotWoods: how will this look for a devloper writing a manifest that only targets new browsers? would you _only_ provide this field?

dmurph: you'd still need `display`, I htink. Could just be `browser`, but you'd add `display_override` in addition

NotWoods: is that confusing? Could we have a world where you only use override if you don't care about back-compat?

dmurph: primary issue was back-compat, as you say. JSON parsers do weird stuff w/ ordering, so we didn't want to touch `display`. Could change this back to be "either"...not require `display`...odd situation, but I'm imagining that developers are looking for docs for each field, but docs would explain fallback chain

marcosc: can you discuss JSON ordering issue?

dmurph: you could set a `display` w/ an array, and a second `display` property w/ a string...one would win, not what folks wnat, would require more hacking around JSON parsing

dmurph: would like to still support `display` for compat reasons...you're right, though, that this is weird

aarongu: my only other comment is that we need to make this clear to developers that this is only necessary that you only need this if you want _different_ fallback behavior

aarongu: as for only having one or the other, technically nothing is required

NotWoods: should we support the new fields in `display` too?

NotWoods: should we require the array for newer types?

<discussion of where a theoretical `tabbed` type would be allowed>

dmurph: I'd prefer that be in the array; would otherwise need to spec the strict fallback ordering

dmurph: we can think of cases where folks don't want the set-in-stone-fallback-order

NotWoods: would be confusing to say "use `display`, except for these cases..."

slightlyoff: to NotWoods point, supporting a valid value in _either_ location seems like a good "v2" solution

<discussion of name of properties>

aarongu: tabbed is one of these situati8ons where feature set configuration with 4 modes with options might prevent the need to add new modes in the future?

dmurph: there's a section on this in the explainer; e.g. pieces around back button...proposed a way for the developer to create an alias (e.g. "tab without back button"), with explicit fallback order

<christianliebel> https://‌github.com/‌WICG/‌display-override/‌blob/‌master/‌explainer.md

<discussion of name>

aarongu: I was arguing for "fallback" in the name...but if it's going to do more work futher down the road, maybe that doesn't make as much sense?

dmurph: how do folks think about `display_fallback_chain` or `display_fallback_list`?

<aarongu> Discussion of display_modifiers: https://‌github.com/‌WICG/‌window-controls-overlay/‌blob/‌master/‌explainer.md

dmurph: could do `fallbacks`? descriptive enough?

slightlyoff: timebox the bike-shedding?

Badge renamed to monochrome

<marcosc> https://‌github.com/‌w3c/‌manifest/‌issues/‌905

<marcosc> MC: we were wondering if it had landed in Chrome

<marcosc> TO: It looks like it did land.

<marcosc> DM: Not sure if I can answer if this has shipped or anything yet, but will get confirmation.


<marcosc> RRSAgent make minutes public

Summary of action items

  1. dmurph to write up conclusion from this discussion for inclusion
Minutes manually created (not a transcript), formatted by scribe.perl version 123 (Tue Sep 1 21:19:13 2020 UTC).


Succeeded: s/Mpas/Maps

Succeeded: s/confrim/confirm

Succeeded: s/spc/spec

Succeeded: s/updates/update

Succeeded: s/brough tthis/brought this/

Maybe present: AK, CL, KC, MC, NotWoods, tiger, TS