323041 - Software update dialog steals focus / wait for idle before prompting

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P4)

Description

[Steve Chapel]

The way the software update dialog pops up unexpectedly and steals focus from the existing window is very intrusive. It always seems to happen when I'm playing a Shockwave game, often killing a player. Worse, if a user is typing or clicking in the right place when the dialog appears, the user could accidently press one of the buttons. Perhaps it could even cause dataloss. Compare to bug 315448 for Thunderbird. I'm seeing this problem with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060109 Firefox/1.6a1

Comment 1

[:Gavin Sharp [email: [e-mail]]]

The "accidentally pressing a button" problem was fixed in bug 311288.

Comment 2

[Darin Fisher]

I think we should consider changing the popup dialog to be a notification icon in the toolbar or statusbar (again).  Given that the popup only appears once the entire update has been downloaded (in the background), the user really doesn't need to take any action other than to restart FF anyways to trigger to application of the update.  My only concern is that without the popup dialog, the user may be really surprised to see the update progress meter the next time they launch FF.

Comment 3

[Rowan Lewis]

How can it be fixed if it still happens?

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20060414 Firefox/2.0a1

Comment 4

[liquidcoooled]

Hi,

I am also strongly affected by this bug.
I type looking away from the screen, and often press return just after seeing a flash of something.
The update occurs at the wrong time.

Can I suggest adding a preference to the update mechanism to:

"Only check for updates during New Window or Tab"

That way, the system is almost guaranteed to NOT be in use anywhere else.

This would make me relax and even make me switch the updates back on.

Comment 5

[Matt Mizzi]

(In reply to comment #2)
> My only concern is that without the popup dialog,
> the user may be really surprised to see the update progress meter the next time
> they launch FF.
> 

How about a little warning as the user closes Firefox, a bit like (or maybe combined with if appropriate) the "You are about to close X open tabs" warning. Something like "New updates will be applied the next time you start Firefox."

Comment 6

[(not reading, please use [e-mail] instead)]

> How about a little warning as the user closes Firefox, a bit like (or maybe
> combined with if appropriate) the "You are about to close X open tabs" warning.
> Something like "New updates will be applied the next time you start Firefox."

we're past the l10n freeze for something like this.

so if we were going to solve this for ff2, we'd need another idea.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Does this also happen for the new nsis installer?

Comment 8

[Robert Strong (they/them - no direct email)]

(In reply to comment #7)
> Does this also happen for the new nsis installer?
No, but with the installer it is an entirely different scenario

Comment 9

[Spencer Selander [greenknight]]

This doesn't seem to occur on all sites. I did some testing, when I had a Mozillazine Forums PM window open, the update dialog didn't pop up. Instead, an icon appeared in the Task Bar, flashing orange. This is how it should work everywhere, IMHO; it's plenty to get the user's attention, but doesn't interfere with what they're doing.

In a Yahoo mail "Compose" window, the dialog did pop up. If the "Restart Firefox Now" button was pressed in either of these cases, session restore retained the text that had been typed; but this might not be the case on sites that don't allow persistent login.

This really needs to be fixed; the two-second delay before the "Restart..." button becomes active has not proved effective in preventing all data loss, incidents are frequently reported on the help forums. For instance: http://forums.mozillazine.org/viewtopic.php?t=550198&highlight=

Note that this user was on a public computer, and session restore wasn't available. Users who don't touch-type are likely to be looking at the keyboard instead of the screen, so a two-second delay isn't really adequate for them. Others are complaining about this dialog popping up during games; not a data loss issue but a big annoyance.

Comment 10

[Mats Palmgren (inactive)]

Hendrix feedback:

Name:    Cathy Miller
Email:   phonequeen007atearthlinkdotnet
Product: Firefox
Summary: your update just screwed up something I was trying to add to a website - ruined an hours worth of work!!

Comments: 
I'm really annoyed.  I was inputting info onto a website and it was lost
because your annoying update request popped up and I accidentally hit
the update button while I THOUGHT I WAS TYPING.  As it started it's
update, everything I had already typed just disappeared.  YOU NEED TO
FIX THAT!!!!!!  If your updates can't operate in a multi-tasking
environment w/o negatively affecting the other tasks, then you need to
NOT offer updates!!!!!

Browser Details: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Comment 11

[Robert Strong (they/them - no direct email)]

This could be solved by bug 347585 so adding dependency.

Comment 12

[(not reading, please use [e-mail] instead)]

we could use the cool, new, nsIIdleService for this.

on timeout, if we've been idle for more than <x> minutes, throw up the update ui.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It's not only the update dialog which steals the focus. Also when the application is restarted after the update it steals the focus from another running application.

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #12)
> we could use the cool, new, nsIIdleService for this.
> 
> on timeout, if we've been idle for more than <x> minutes, throw up the update
> ui.

Exactly what I thought (bug 347585 comment 9). A few seconds should be fine though, no need to wait minutes.

Comment 15

[(not reading, please use [e-mail] instead)]

henrik, can you spin your comment #13 to another bug?

dao:  thanks for commenting about idling.

Comment 16

[Przemyslaw Bialik]

So you Seth decided to take this bug and not yours (Bug 351471), strange ;)
If updated description is the solution for this bug then now they are duplicates.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #15)
> henrik, can you spin your comment #13 to another bug?

I filed bug 399580 for that issue.

Comment 19

[Bob Triffles]

In my opinion, the dialog should never alter the focus, regardless of the idle time.  The user could press Enter at any time.  I believe focus should always be under the user's control.  Ideally, an unfocused dialog, notification balloon, or other background mechanism would be used.

But waiting for idle is far better than the current situation, which just caused me to accept an update when I was trying to enter a URL.

Comment 20

[Dão Gottwald [:dao]]

Attachment: proposed patch

Comment 21

[Dão Gottwald [:dao]]

Attachment: proposal v2

that's better

Comment 22

[(not reading, please use [e-mail] instead)]

Comment on attachment 289322 [details] [diff] [review]
proposal v2

r=sspitzer

1)

Is the second 'case "idle":' necessary?

2)  is 10 seconds enough idle time?

Comment 23

[Dão Gottwald [:dao]]

(In reply to comment #22)
> Is the second 'case "idle":' necessary?

I don't think so; I'll test it.

> 2)  is 10 seconds enough idle time?

I think it is, at least it should eliminate most of the focus stealing. If we wait too long, users who run Firefox for short time spans (e.g. start, check mail, quit) will never get notified.

Comment 24

[Dão Gottwald [:dao]]

Attachment: patch v2.1

removed the superfluous case

Comment 25

[Dão Gottwald [:dao]]

I think we should get this in and file a new bug to figure out the best idle time; hopefully there will be feedback from nightly testers to build upon.
Objections?

Comment 26

[(not reading, please use [e-mail] instead)]

Comment on attachment 289403 [details] [diff] [review]
patch v2.1

>  Objections?

none at all.

I agree, let's get this in there.

Comment 27

[(not reading, please use [e-mail] instead)]

actually, can we do 60 seconds of idle instead of 10?

10 seconds seems fast, especially for accessibility users

perhaps faaborg or tim can comment on what is a good value?

actually, perhaps instead of hard coding it, let's make it a hidden pref that can be overridden:  app.update.<something>

Comment 28

[Dão Gottwald [:dao]]

Attachment: patch v3

Comment 29

[(not reading, please use [e-mail] instead)]

Comment on attachment 289408 [details] [diff] [review]
patch v3

r=sspitzer, thanks dao!

Comment 30

[Reed Loden [:reed]]

Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.228; previous revision: 1.227
done
Checking in calendar/sunbird/app/profile/sunbird.js;
/cvsroot/mozilla/calendar/sunbird/app/profile/sunbird.js,v  <--  sunbird.js
new revision: 1.46; previous revision: 1.45
done
Checking in mail/app/profile/all-thunderbird.js;
/cvsroot/mozilla/mail/app/profile/all-thunderbird.js,v  <--  all-thunderbird.js
new revision: 1.100; previous revision: 1.99
done
Checking in suite/browser/browser-prefs.js;
/cvsroot/mozilla/suite/browser/browser-prefs.js,v  <--  browser-prefs.js
new revision: 1.71; previous revision: 1.70
done
Checking in toolkit/mozapps/update/src/nsUpdateService.js.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in,v  <--  nsUpdateService.js.in
new revision: 1.144; previous revision: 1.143
done

Comment 31

[Alex Faaborg [:faaborg] (Firefox UX)]

>actually, can we do 60 seconds of idle instead of 10?
>10 seconds seems fast, especially for accessibility users
>perhaps faaborg or tim can comment on what is a good value?

I agree that 10 seems a bit fast, anything in the range of 30+ seems ok.  If we set it too high then users might got for awhile before seeing the update, and there is some incentive to get these updates applied quickly for security fixes, right?

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Wouldn't it be a good solution to show a status bar icon if an update is available? Darin already mentioned this way in comment 2. Seems that his idea was getting lost. In this case the user will be informed even he is not idle over a longer period of time.

Comment 33

[Alex Faaborg [:faaborg] (Firefox UX)]

We had what some people called the christmas tree in Firefox 1.5 appear next to the throbber (looked like a green circle with an up arrow).  I believe the problems included the fact that user's didn't know what it meant, didn't know they should look for it, and didn't really want to bother with clicking on it when they did see it.

Comment 34

[Ben Frisch]

What about using the notification bar, ex the same bar used to remember passwords and show popups to display that extensions and browser updates need to be applied?

This type of notification is encounter more frequently than a window and the user will be more likely to read.

Perhaps the option could be install and restart now or restart later just like the current dialog.

Comment 35

[Alex Faaborg [:faaborg] (Firefox UX)]

>What about using the notification bar, ex the same bar used to remember
>passwords and show popups to display that extensions and browser updates need
>to be applied?

These types of notifications are generally used for site level events as opposed to browser level events.  We could potentially use a browser level notification (like we do for download complete, using GROWL on OS X and custom little messages on Windows and Linux).  Although overall I agree with beltzner that we should just silently update, and only prompt the user if they haven't restarted their browser in a long time.  Asking first is illogical, because there is no way for users to know ahead of time if they want to install or not.  Instead we need to support undo (for the extremely rare case when we accidently regress and the new version causes issues on a site the user has to use).

Comment 36

[Carsten Book [:Tomcat]]

Litmus Triage team: Tomcat will create a testcase for this

Comment 37

[Carsten Book [:Tomcat]]

testcase created, setting in-litmus flag.

Comment 38

[Alex Polvi]

(In reply to comment #31)
> >actually, can we do 60 seconds of idle instead of 10?
> >10 seconds seems fast, especially for accessibility users
> >perhaps faaborg or tim can comment on what is a good value?
> 
> I agree that 10 seems a bit fast, anything in the range of 30+ seems ok.  If we
> set it too high then users might got for awhile before seeing the update, and
> there is some incentive to get these updates applied quickly for security
> fixes, right?
> 

just wanted to point out that I was watching a video online today, and got prompted... was super annoying to have it wait until I was watching something. 
What about making it something like 10min, instead of seconds?

Comment 39

[Steve Chapel]

The problem is that it still steals focus. That's the original problem I reported. Now, instead of interrupting a game, it interrupts a video. I like the notification bar idea, as it does not steal focus.

Comment 40

[Henrik Skupin [:whimboo][⌚️UTC+1]]

A while ago I talked with Alex on IRC about that topic. As he also said in comment 35 a global notification would be helpful. I filed bug 412067 therefor.