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

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

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.

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

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.

(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."

> 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.

Does this also happen for the new nsis installer?

(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

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.

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

This could be solved by bug 347585 so adding dependency.

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.

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.

(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.

henrik, can you spin your comment #13 to another bug? dao: thanks for commenting about idling.

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.

(In reply to comment #15) > henrik, can you spin your comment #13 to another bug? I filed bug 399580 for that issue.

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.

that's better

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?

(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.

removed the superfluous case

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 on attachment 289403 [details] [diff] [review] patch v2.1 > Objections? none at all. I agree, let's get this in there.

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 on attachment 289408 [details] [diff] [review] patch v3 r=sspitzer, thanks dao!

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

>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?

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.

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.

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.

>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).

Litmus Triage team: Tomcat will create a testcase for this

testcase created, setting in-litmus flag.

(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?

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.

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.