When dragging a file into Firefox we should show an in-content UI for the doorhanger to attach to, see https://bug1120996.bugzilla.mozilla.org/attachment.cgi?id=8598797 We could also use this for the install-from-file option in the add-ons manager.

I need to figure out the behaviour here: When a new install starts do we replace the current tab with this UI or open a new tab? When the install completes or is cancelled what happens to the tab? If there are multiple add-ons being installed do we just list all the names?

As I see it we have 2 options. 1) A basic drag and drop UI in the line of how dragging files in the browser currently works. (compare dragging images, pdfs, links, html files) Which only accepts one file at a time, and overwrites the page in the active tab, and keeps the tab open, till closed. (The existing concept is based on that premise.) 2) Or we go for an advanced solution accepting multiple files and processing them in about:addons. Which we kind of currently do in about:addons, which accepts multiple files, but does not show it's advanced drag and drop capabilities. This could be visualized like uploading files to dropbox or google drive. The attached file illustrates this flow. If we do that, we could catch any dragged xpi anywhere and handle it inside about:addons instead of opening a new tab. I think both solutions work, but 2 is definitely nicer. But more work as well. And I might need some time to finish the flow. What's your thoughts on that? Do we have the resources for 2? (In reply to Dave Townsend [:mossop] from comment #1) > When a new install starts do we replace the current tab with this UI or open > a new tab? If the user drags the file on a tab, we should replace the content of that tab, as we do with any other file that is dragged into the browser (except if the page itself has a drag and drop interface e.g. for file upload like dropbox, google drive etc.). If the user wants the file to open a new tab, they can drag the file to the tab bar. (1) As an advanced state (2) we can consider providing a drag and drop interface in about:addons (like dropbox, google drive) to "upload" the add-on instead of replacing the content. I've noticed that about:addons currently does something like that, but without indicating it in the UI. (It even treats pictures as add-ons which it states are corrupted. Without any visual feedback that this page accepts the dragged content, I would not have expected that.) > When the install completes or is cancelled what happens to the tab? For the simple case of dragging one xpi on one ordinary tab, I would expect the tab to stay and a reload to trigger a new installation (e.g. to update).(1) For about:addons we either treat it as an ordinary tab (1), or we visualize the drag and drop & install capabilities of the page (like dropbox, google drive)(2). If we do so, I would treat the install as coming from about:addons and not replace about:addons with the basic drag and drop interface. > If there are multiple add-ons being installed do we just list all the names? Currently about:addons handles multiple add-ons well, except that it does not visualize receiving them. Having one doorhanger for multiple add-ons seams to be a good solution in that case. As basic tab behavior we currently do not support dropping multiple add-ons (or files in general) a tab only uses one of the files, and the tab-bar rejects it completely. So this behavior depends on which solution we prefer. (1) does not allow multiple, but we could build an exception, (2) does allow it.

I did talk this through with Philipp today and we think that no UI changes are really necessary for this special case. Let's keep the current behavior but enable multiple add-ons to be dragged anywhere, not just about:addons. (except pages that have a drag and drop function themselves)

(In reply to Markus Jaritz [:maritz] (UX) from comment #3) > I did talk this through with Philipp today and we think that no UI changes > are really necessary for this special case. Let's keep the current behavior > but enable multiple add-ons to be dragged anywhere, not just about:addons. > (except pages that have a drag and drop function themselves) To clarify, we already support drag and drop of multiple add-ons anywhere. The in-content UI we're talking about here will be shown whenever dragging an XPI into the content area to start install, when tying the url to an add-on direct into the address bar and when using file - open. In all cases we need to hide the existing page to make the doorhanger make sense. If you want to just open the add-ons manager instead to display those cases then I can do that though it seems a little busy. The original mockups you showed look simpler but I don't know how to display multiple add-ons in that case.

(In reply to Dave Townsend [:mossop] from comment #4) > To clarify, we already support drag and drop of multiple add-ons anywhere. I tested dragging multiple add-ons in Nightly but always only one add-on showed as being installed. Except in about:addons, where both add-on names appear in the same doorhanger, which is perfect. If this behavior also works on any other tab that will be fine. > The in-content UI we're talking about here will be shown whenever dragging > an XPI into the content area to start install, when tying the url to an > add-on direct into the address bar and when using file - open. In all cases > we need to hide the existing page to make the doorhanger make sense. I understand that a doorhanger over a random page is not a perfect solution, but as this is an expert feature, and as the doorhanger appears directly after a user action (drag, type, open), we can assume the user will know what is going on. So as an expert feature not showing a UI is a little less clear, but more efficient as we will not replace a page, or deal with an additional open tab. (And might save some development effort.) So we think it is good enough without showing the UI I suggested.

Having the location shown in the install-doorhanger as shown in my mocks would help to show where the installed add-on is coming from. Is there a bug for that being added?

Sounds like showing an in-content UI is a wontfix then.