PWA Dev Sync meeting notes - Tue Mar 29, 2022

[Hoch Hochkeppel]

Tue, Mar 29, 2022 (Hoch is MCing)

• Look for scribe volunteer(s)
  • Primary: dmurph@
  • Secondary: Hoch
• [penny] Changing PWA install criteria 
  • Removing installability check requirements 
  • Thoughts on adding an imperative call to install such as navigator.install to the spec 
    • How to protect users from spam: gate on user gesture? 
  • Looking at standardizing install as a capability of a browser with user control, as opposed to a feature that is locked to developer under certain criteria
  • Goal
    • Make install something that is under the user's control. Instead of a developer carrot.

• • • • "capability a user can choose to exercise on any webpage that they would like to make permanent"
    • reconcile create shortcut behavior with install behavior
    • offer something more imperative as opposed to the beforeinstallprompt event
    • something like navigator.install
  • Significant change!
  • Pages that do not have information required today for install, we would fall back to "create shortcut" behavior like
    • favicon for icon
    • page title for pwa name
  • Q: Should we preserve the beforeinstallprompt API to help with promotion?
    • We should keep it around for some time as sites have implemented it, and we can still use it for install promotion on browser surfaces
    • Open question: do we show the install icon in omnibox all the time? Probably not. We could use promotion to show that (like we do now), and beforeinstallprompt works with promotion.
    • Having install criteria for further promotion for product help or omnibox is useful. This might not imply total removal of install criteria. But having the install capability accessible for users is a net win allowing users to choose to install something.
    • Q: On the Android side, where the install banner is a bit more intrusive.
      • it prevents promotion entirely on Android. On desktop, it doesn't prevent anything,  it just allows the dev to show the install dialog on demand
      • Android - we can look at preferred related apps to know if we should show that banner as opposed to install criteria
      • We should act on behalf of the user's interests here instead of relying on developers.
      • We should take the hint of prefer related app.
  • We shouldn't show the short-sheet if the manifest has preferred related apps.
  • interested in how we 'gate' the imperative install API so we don't end up with situations like notification & location right now
    • we can disallow this API if too many users decline
    • we can start with only user gesture gating, and add more restrictions if there is abuse.
  • Alancutter@ - we prevent showing notification prompt if too many users decline?
    • it's a bit more complicated, we do something called silent notifications
    • but yes, we will auto-block notifications (user is notified of this) for really bad sites
    • if the site is maybe-good maybe-bad, the notification is no longer interruptive
    • trick is because install isn't a permission, we can't really take this exact same approach.
  • "ask to install" could be a permission
  • could use site engagement score - but it basically means (did user click on site)
  • Q: where would install option be?
    • There would be an option in the overflow menu to install any site
  • How do we distinguish the "create shortcut" and "install" behaviors for users?
    • We might want to have it be developer-controlled, they must use a manifest for certain behaviors
  • FYI - create shortcut behavior change in chromium is being considered
    • creating shortcut for specific url gets overriden when that site has a manifest & gets upgraded
  • If we add a generic install for all sites, it gets used enough for non-web-app sites for us to figure out how to deal with that
    • make change first, maybe folks don't really install non-web-app-sites
• [Daniel] dPWA Infra improvements planned for Q2
  • Richer install modal
    • Install should be like a web store install - screenshots, capabilities, etc.
    • User improvement. Privacy & security improvement.
  • dPWA Commands & Command Queue (bit.ly/dpwa-commands)
    • There is a lot of async reading/writing to 5? different locations, leading to a lot of operations potentially racing each other (installs, uninstalls, etc.).
    • We want to add more metrics to be able to measure improvements.
    • We are hoping this will solve a lot of the icon issues people have been seeing.
    • General idea - reading/writing will only be available inside a Command.
      • Creating an exclusive lock on app ID (or multiple app IDs if needed).
      • [Alan] This sounds a lot like problems with WebContents and wanting to prevent multiple background ones from consuming lots of resources.
      • [Daniel] That seems related, though slightly more related to the underlying global queue.
    • Questions are welcome on slack.
  • OsIntegrationManager sub-manager interface & structure (bit.ly/os-integration-sub-managers)
    • Lots of layers of overrides exist today regarding OsIntegration. This is an attempt to cleanly structure it all in one spot, which should increase execution speed (as well be easier to maintain).
    • Might not be done in the quarter, but the important parts will be getting addressed first.
• [Daniel] Verify that Edge doesn't have any "Chrome App"s supported.
  • extension->is_app()
  • alancutter: Are there flags Edge can enable to try to see if Chrome app installation is supported?
  • Currently being aggressively deprecated. If Edge has any, be ready.
  • https://chrome.google.com/webstore/detail/xylophone/mahcppaeicapblojigmihidmephnikkl?utm_source=chrome-ntp-launcher
• [alancutter] Manifest versionupdateToken field general discussion.
  • How do we update icon & titles for web apps?
  • Problem: we don't want to show many prompts to the user when sensitive manifest members are updating
    • icon
    • name
    • ... file handlers in the future?
  • Solution: Field that the developer would have to update, which would trigger a possible update of these security sensitive fields.
  • Could we see version being added in the future?
    • [Daniel] Yes - we have gotten the feature request from 'web app store' folks that they want to be able to display a version to the user
    • User can be in wild west of web
    • or user can be in a web store
      • the store controls the web bundle very directly, code signed, etc
      • updates are facilitated by the developer telling the store, and the store facilitates the update (increases version)
    • This API could be still compatible with the web store wants of a version
    • We could have a 'changelog' that the store reads, instead of a version
      • this might accomplish what users want from a 'version' in the web store
  • Using the same `version` field for both the identity updating and what the store displays to the user.
  • mini app manifest has a version field
    • https://www.w3.org/TR/miniapp-manifest/#version-member
    • version code -> text to show the user.
  • another proposal: changes to the manifest_url
    • `/my/manifest.json?version=2`
    • no thread of collision with a version or changelog in the future
    • similar to how serviceworkers update now
    • would be nice if we could install web apps by manifest url. Manifest url update would make this a bit weird
    • The query string is easily discarded here, so it's not hard to implement this.
    • "we reserve the right to show update to user, and if you change the manifest url, we are even more encouraged to show the update dialog for the user"
    • main con from Dan - this does 'move out' knowledge about how web apps work from the manifest into another little part of the platform.
  • What does Edge think?
    • version field - worry about introducing a non centrally controlled verion number
      • assumptions about versions going up or down
      • versions can also be unique per distribution platform
    • updateToken - just string difference for update
    • agreed - would love solution to icon update issues
    • other idea
      • if the problem really is that some sites change theirs too regularly
      • we could add a permission to 'always trust icon changes to this site'