616100 - Remove redundant install delay (undo fix for Bug 162020)

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Terrell Kelley]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7) Gecko/20100101 Firefox/4.0b7

The install delay was implemented in order to avoid a user accidentally clicking on the install button unknowingly while following an unscrupulous web designer's instructions. This delay is unnecessary with the advent of the two-click solution we use today.

On any site other than http://addons.mozilla.org, or a site the user specifically allows, a warning is issued when a site tries to install an extension. This warning is at a completely different place on the screen than where the install box pops up, and it is very unlikely for any user to accidentally click both spots in succession. And, on the Mozilla Add-ons website, the exploit is impossible without the site being hacked, as submitters and commenters have no way of controlling the position of items on the screen. However, I would not object to the warning becoming universal.

It was pointed out in Bug 162020 that a two-click solution was sufficient. It is also what all competing web browsers use, including those like Google Chrome that have just as high a security rating. Plus, as the number of people who download extensions to get around it prove, it is considered very annoying to a large base of users. The javascript engine included in all versions of Firefox is more risky that this fix,

The only purpose it serves is to give people a false sense of security. With the advent of Firefox 4 around the corner, it would be nice if we would move with the times and use the more modern, less frustrating solution which has (mostly) already been implemented, rather than keep a useless security measure for our peace of mind.

Thank you.

Reproducible: Always

Steps to Reproduce:
1. Try to install an extension.
2. Get a warning, click allow
3. Still have to wait 3 or more seconds to Install.
Actual Results:  
See above

Expected Results:  
No delay--the two click solution is sufficient.

Comment 1

[Jesse Ruderman]

> It was pointed out in Bug 162020 that a two-click solution was sufficient.

I'm pretty sure you haven't read all of bug 162020.  Requiring two clicks on different parts of the screen might be sufficient for mouse-only input, but you also have to consider touch-screen input and mouse+keyboard input.  Might as well have a delay; I think we can make it short enough that most mouse-only users won't notice.

> It is also what all competing web browsers use, including those like Google 
> Chrome that have just as high a security rating.

Chrome uses a delay too.  But instead of disabling a button, it uses an animation (on Mac) or just acts slow (on Windows).  Tested using the official Chrome extensions gallery, which by the way does not ensure the two clicks are on different parts of the screen.

Chrome's "show the dialog slowly" strategy seems worse than Firefox's "show the dialog quickly but don't allow immediate clicks" strategy.  It actually forces users to wait longer than a minimal Firefox-style delay.

We plan to shorten the delay from 2s to 1s, reduce its visual impact, and reduce its performance impact by letting the download happen concurrently.  I hope most users will find this preferable to Chrome's (intentional??) slowness.  I'll post links to our plans, including bug numbers tomorrow.

Comment 2

[Terrell Kelley]

First off, I assumed the keyboard problem was already dealt with: input should not be accepted until the user has had time to perceive the dialog, which gives you a good 250 ms or so. Furthermore, being able to steal focus from a text box like that seems to be a bug in and of itself. Once a user is in a text box, they tend to not like being taken out of it unless they have left it explicitly by pressing TAB, ENTER, or clicking out.

Second, a slide in animation is not considered a delay to the user (and in fact, the actual delay was not perceived by this user until you told me it was there). The user expects the dialog not to be available until it is safe to click on. Once you display something, it's assumed to be active. That's why the current Firefox dialog box has to be so obvious about the delay, and, as we both know, the user noticing the delay is what creates the problem, not the delay itself.

When I refer to removing the delay, I mean to remove the perception of a delay. I believe the average user does not notice the delay in Chrome because its animation is an expected part of the UI. It is my understanding that Firefox is also going to be adding a lot of animation. A fade in on the first extension doorhanger (if not doorhangers in general) would almost certainly fit in perfectly.

But that's not the only solution. Another would be to simply create a minimum amount of time between the start of the download and the install dialog. The animation would just be the progress bar in the download doorhanger, which can be artificially slowed if necessary. The user expects a download to take a little bit of time.

I'm not sure how the above would work if you allow downloading in the background, so that may not be that good an idea. But whatever you do, displaying a full dialog that you cannot immediately use does not seem to be a good choice. It is contrary to almost every UI I have ever seen, and we are trying to be consistent with the OS and its main applications.

I will also continue to say that any delay on AMO seems silly, and is probably why my (extremely simple) addon for removing the delay is as popular as it is. Anyone who tries out a lot of extensions is likely annoyed by the slow process. Installing addons in Chrome definitely seems faster from official sources--many don't even have a dialog box. It's quite similar to how installing an addon from the Addon dialog works.

But, anyways, thank you for addressing this annoyance, and thank you for explaining what you are doing. I also appreciate including the appropriate bugs, as the only one I found in search was the one I mentioned in the initial report.

Comment 3

[Jesse Ruderman]

The overall project and plan are now being documented at
https://wiki.mozilla.org/Extension_Manager:Projects:Improve_Add-on_Installation

We'll keep in mind the possibility of replacing the security delay with an animation (for users who have animations enabled). It's a rare case of actual speed and perceived speed being at odds with each other.

Let's see how unhappy users are after we merge the dialog and download waits (bug 652896) and reduce the delay to 1 second (bug 416605).