Currently add-on install is initiated by the user. This starts the download that can last an undefined amount of time. Only after that is finished the user can confirm that they truly want to install the add-on. Can we optimize the process to only need one interaction for the optimum case? (as suggested here https://bugzilla.mozilla.org/show_bug.cgi?id=1120996#c36) e.g. click install and everything is done in the background, unless some problems arise.
Created attachment 8591672 [details] 150413_Add-on-Process-Vision.gif Can such a streamlined install process be as simple as shown? What would it take to make it as simple? Only for certified add-ons of course.
By certified, do you mean signed?
Yes. That is what I meant.
Dave, I have been talking to Andy today about improving the install flow for WebExtensions. I remember a conversation we had a view month back where you mentioned that having such a shortened install-process as suggested here would require some different behavior in how the add-on is sent to the browser, or some separation of manifest and add-on... Andy and I would love to optimize the install flow for WebExtension, but we are currently unclear on what the best next steps would be to move towards such a simplified install-process. Could you please help us break down this work. Thanks.
(In reply to Markus Jaritz [:maritz] (UX) from comment #4) > Dave, I have been talking to Andy today about improving the install flow for > WebExtensions. I remember a conversation we had a view month back where you > mentioned that having such a shortened install-process as suggested here > would require some different behavior in how the add-on is sent to the > browser, or some separation of manifest and add-on... > Andy and I would love to optimize the install flow for WebExtension, but we > are currently unclear on what the best next steps would be to move towards > such a simplified install-process. Could you please help us break down this > work. Thanks. Currently we have to download the entire file before we can know what kind of add-on it is. To avoid that we would probably need to add to the existing JS API that webpages can use to install add-ons to include whatever information you need. I'm not sure why that would be needed though, what about the new install process would be different between web extensions and old-style extensions?
(In reply to Dave Townsend [:mossop] from comment #5) > what about the new install process would be different between web extensions > and old-style extensions? If we can optimize the flow for all extensions, it would even be better. I mentioned WebExtensions because they are currently in the making, which made me hope that changes there might be easier. Andy, did that feedback help. I have no understanding of what such changes to the JS API would be.
Looks like a somewhat similar request has been made years ago. For reference: bug 652896
If this is only for signed add-ons, we'd need to know if the add-on is signed before we start the download and install process. For that we'd need to have some way of signalling that an add-on is signed up to Firefox before we start. Markus I think what might help here is a flow chart of the non-happy use cases. Some of the things that I can think of are: * what happens when an add-on claims its signed but isn't? * what happens to unsigned add-ons? * what happens if an add-on is not on AMO? * would this change on the add-on type, for example with a legacy XUL base add-on or web extensions? * would we want to do anything if the add-on is large (this can affect mobile for example) I think once we've got a clear flow of the proposition, we can come up with the kind of data we'd like to have in a manifest (assuming we need one) and what sites other than AMO would have to do. The happy path of removing the install dialog and showing the notification is completely cool for me in the ideal situation. We should just clarify what that is.
This bug was added to the discovery pane tracker because I believe this is part of the UX for the improved discovery flow. For that flow its really only talking about the flow for *addons.mozilla.org* only, there are other bugs for other sites. I think the key changes could be something as simple as: * If the install starts from addons.mozilla.org, remove the "This site would like to install an add-on: Cancel / Install" dialog, the point being that the request and intent had already been made. * Change the message after install to instead point to a button added to the toolbar, if one exists and the add-on is restartless. Those two changes would make the install flow require no user interaction, but would still provide them feedback. If anything goes wrong in the install flow, such as the addon can't be downloaded, isn't signed or the stars just are aligned wrong, we'll default to the usual error messages. Would that work?
Sounds good. One thing I miss in your summary is the state of the button - indicating if the add-on is already installed or not. We will also need to define the details of the confirmation message. I do not think we can use the existing one for that. And for all other messages we need to define where to anchor them to. Themes and buttonless add-ons could be anchored from the menu-button. pwalm will map out those flows in more detail this week. (building this for all of AMO instead of only for our set of discovery add-ons broadens the scope somewhat, as all discovery add-ons are restartless and have a button in the toolbar, which omits some edge cases.)
The APIs are exposed up to the disco pane and AMO, I think this is done.