We want installs from websites, drag-drop etc. to display using the same UI that we are going to use for installs by third parties on startup (bug 476430). For the Get Add-ons pane we should just display the UI in that pane rather than open a whole new tab.

Initial mockups from Alex

The button should be labeled "Add to Firefox" or "Install", not "Continue". There should be a "Cancel" button and it should have focus.

yeah, that was a complete mistake (we were using this "you must check the checkbox" trick in the design for local extensions): http://people.mozilla.com/~faaborg/files/firefox4Mockups/userAddonSelection/addOnLocalInstall-i2.png I totally agree that we should have the normal two controls for Web-based installs. Also, in the special case of AMO I think this would work a lot better as a tab-modal panel, so that the shift isn't as jarring. For sites that are not AMO (but the user has granted permission), we probably want the shift to be a bit jarring.

This has some updates to correct mistakes in the previous mockup, and makes the install process more intentional (check box to confirm trust, followed by clicking install button): http://people.mozilla.com/~faaborg/files/projects/addOnInstallOnline/addOnInstallOnline.htm# I think that a full tab interface like this is better than the use of a doorhanger for two reasons: 1) helps the user to focus entirely on what is being asked 2) contains multiple sequential stages: ask > download > confirm/error Note that a doorhanger would still be used for sites (that are not AMO) to ask permission if to even be able to produce these tab confirmations of extension installs. So we would still get the click outside to close properties of the arrow panel before the user ever got to seeing these types of questions.

Do we really want 3 clicks to install, though? And does changing focus do anything for keyboard text based attacks? (I'm under the impression that we are maintaining keyboard accessibility). I also think that, with a "trust" checkbox, users are going to expect that to apply to any addons from that site from then on. That's what trust usually means in this context. If that is not what we mean, I think we need to look at the wording, at the very least. Finally, are we planning to include any opt out/streamlined options for people who test a lot of addons? You know, like setting security.dialog_enable_delay to 0 is often used now?

This bug could also solve bug 657581.

Any plans for this at the moment?

(In reply to Brian King (Briks) [:kinger] from comment #8) > Any plans for this at the moment? I have a series of WiP patches for this, just need to find time to finish it all. It's a lot of work, and there's other stuff I need/want to finish first, so it'll probably be awhile.

(In reply to Blair McBride [:Unfocused] (I don't read bugmail - needinfo? me!) from comment #9) > (In reply to Brian King (Briks) [:kinger] from comment #8) > > Any plans for this at the moment? > > I have a series of WiP patches for this, just need to find time to finish it > all. It's a lot of work, and there's other stuff I need/want to finish > first, so it'll probably be awhile. Any further progress on this ? I note this is blocking the bug that results in the AMO footgun [:Boriss] bug 646602 comment13 > .... a larger problem is that Mozilla appears in this dialog to be at war with itself. > "Firefox" should never tell the user it's blocked a mozilla.org site. > Ideally, this dialog would never appear on AMO at all. ....

This bug is getting obsoleted by bug 1120996

Indeed, that bug means everything here gets thrown away.