Re: [w3c/manifest] Web Install (Issue #1178)

dmurph left a comment (w3c/manifest#1178)

[Conversation at TPAC](https://docs.google.com/document/d/1fOjXiGUFf_krkfYaWf5drbqzY7CTxn7EcDYr5ZWjzFg/edit?tab=t.cnzoci72snh#bookmark=id.nglzwamowukc)

* Frustration with UI for add-to-homescreen. Nice if there was some imperative means of doing the install  
* previous  \- beforeinstallprompt from Chrome  
  * basis \- it would show a banner (kinda mobile-y) \- prompt  
  * you don't want that from showing while user is doing something, so could trigger it via button click etc  
  * Safari doesn't support it, and supports a 'smart banner', and you use it by not adding the manifest link until you want it to show  
* wouldn't it be cool for navigator.install?  
* idea: Now we have PEPC \- what if we jsut had a button, html button you could just press?  
  * took the API shape from install, to an element  
  * no formal proposal \- but alternative approach  
* beforeinstallprompt \- a lot of usage \- so webcompat issue potentially  
* navigator.install gives us a clean slate, similar to install button as well  
* but doesn't get rid of legacy code that relies on beforeinstallprompt \- if they decide to do a banner /prompt using that API we would need to support that being shown.  
* other things  
  * wow the beforeinstallprompt api is really confusing and hard to use  
    * in the past it wasn't reliable, but now it is  
  * partners that are testing the install API  
    * feedback about how much smoother the experience is (for background page install)  
  * TAG-side  
    * feedback to keep it super simple  
    * API has gone through several shapes. One had a two-way handshake between manifest file and install source  
    * 2 or 3 tag reviews  
* imperative API now pretty simple  
* Christian  
  * I would not like to wait for PEPC button \- I would like to use API \- didn't seem done  
  * seems fairly new  
  * Marcos \- it's not PEPC, it's just the model  
  * navigator.install, 0-params  
  * fallback plan \- reuse beforeinstallprompt \- the API is not nice, confusing. But only have to write it once.  
  * worry here is that , if it was an element, it wouldn't be available soon  
* Diego \- unless we have buy-in from other browser engines on new model, it would be an API on another experimental API  
  * fallback version would be needed if not all user agents supported  
  * does this mean that if we had more swes that could implement on all user agents it would reduce risk?  
  * marcos  
    * the imperative api thing might be red herring  
    * if it's always going to be a button, we should just make it a button \- there is no change for the api surface from navigator.install vs just being a button.  
      * any reason why it should be attached to navigator.install vs just a button  
    * if you had an install button that uses beforeinstallprompt, you can just wrap this with this button itself.  
* Rob  
  * There is one area we have been trying to explore \- 'different document' install  
  * Button for navigator install for 'different document' install is hard  
    * install\_url, manifest\_id, hard to show UX for install button in a trusted way  
      * load install\_url in background  
      * find manifest link  
      * load icon in manifest  
      * (lots of steps)  
    * don't want to fetch the install\_url background fetch until user intervention  
    * ideas  
      * extra manifest\_url on install element  
      * moving to something crazier like one ap per origin  
      * having two clicks \- one click fetches the info, the next installs  
      * or \- it would open the document in a popup or something  
* Diego & Rob \- parameterless version is what is in scope for this convo  
* Christian \- we can extend the install element later on, we can add whatever we want to add there.   
  * Element design seems risky to rely on if our design isn't final.  
  * we should give ability to devs to decide what the install button/add-to-homescren button looks like  
* Kagami  
  * is there risk for spoofing, with API?  
  * Marcos \- the API allows you to lie much more than the element does  
  * Diego \- we can take HTML and CSS and and trick user to click on install button... to ask for something else.  
    * so imperative, dev can create button for not installation, and then clicking on it would trigger install UX  
    * for element, ..... because devs can mimic that look and feel  
      * e.g. we shouldn't have trusted UI at all in an untrusted viewport, as if the user gets used to that, they malicious websites can mimic that and be able to get a 'click' on something (to do something else, like get microphone)  
* Marcos  
  * Let's give ourselves a month to come up with an element proposal, run it internally to see if people are interested.  
  * If it flies, then we should seriously consider the API. We already have a pull request, it should be easy to implement.  
* What prevents merging?  
  * ID or no ID required in the manifest  
  * problem \- the start\_url changing causes multiple apps.  
  * so we want to require an id in the manifest file so that we help encourage the ecosystem to not have this huge problem.  
  * \<active discussion\>  
  * We can solve to say user agents will have different requirements.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/1178#issuecomment-3515105491
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/manifest/issues/1178/3515105491@github.com>