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.
https://github.com/web-platform-tests/wpt/pull/24452
<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?
Adjourn
<dmurph> +p
Agenda
<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.
Adjourned
<marcosc> RRSAgent make minutes public