Software update dialog steals focus / wait for idle before prompting

RESOLVED FIXED in mozilla1.9beta2

Status

()

Toolkit
Application Update
P4
critical
RESOLVED FIXED
12 years ago
7 years ago

People

(Reporter: Steve Chapel, Assigned: dao)

Tracking

({dataloss})

Trunk
mozilla1.9beta2
dataloss
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

10.89 KB, patch
(not reading, please use seth@sspitzer.org instead)
: review+
Details | Diff | Splinter Review
(Reporter)

Description

12 years ago
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.

Comment 2

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
(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
Severity: normal → critical
Keywords: dataloss
This could be solved by bug 347585 so adding dependency.
Depends on: 347585
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.
Flags: blocking-firefox3?
OS: Windows XP → All
Hardware: PC → All
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.
Flags: blocking-firefox3? → blocking-firefox3+

Updated

10 years ago
Target Milestone: --- → Firefox 3 M9

Updated

10 years ago
Assignee: nobody → sspitzer
Depends on: 391598
No longer depends on: 347585
Target Milestone: Firefox 3 M9 → Firefox 3 M10
(Assignee)

Comment 14

10 years ago
(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.

Updated

10 years ago
No longer depends on: 391598
henrik, can you spin your comment #13 to another bug?

dao:  thanks for commenting about idling.
Status: NEW → ASSIGNED
Summary: Software update dialog steals focus → Software update dialog steals focus / wait for idle before prompting

Comment 16

10 years ago
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.
(Assignee)

Updated

10 years ago
Blocks: 394021
(Assignee)

Updated

10 years ago
Duplicate of this bug: 351471
(In reply to comment #15)
> henrik, can you spin your comment #13 to another bug?

I filed bug 399580 for that issue.

Comment 19

10 years ago
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.

Updated

10 years ago
Target Milestone: Firefox 3 M10 → Firefox 3 M11

Updated

10 years ago
Priority: -- → P4
(Assignee)

Comment 20

10 years ago
Created attachment 289321 [details] [diff] [review]
proposed patch
Attachment #289321 - Flags: review?(sspitzer)
(Assignee)

Comment 21

10 years ago
Created attachment 289322 [details] [diff] [review]
proposal v2

that's better
Attachment #289321 - Attachment is obsolete: true
Attachment #289322 - Flags: review?(sspitzer)
Attachment #289321 - Flags: review?(sspitzer)
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?
Attachment #289322 - Flags: review?(sspitzer) → review+
(Assignee)

Comment 23

10 years ago
(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.
(Assignee)

Comment 24

10 years ago
Created attachment 289403 [details] [diff] [review]
patch v2.1

removed the superfluous case
Attachment #289322 - Attachment is obsolete: true
(Assignee)

Comment 25

10 years ago
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.
Attachment #289403 - Flags: review+
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>
(Assignee)

Comment 28

10 years ago
Created attachment 289408 [details] [diff] [review]
patch v3
Attachment #289403 - Attachment is obsolete: true
Attachment #289408 - Flags: review?(sspitzer)
Comment on attachment 289408 [details] [diff] [review]
patch v3

r=sspitzer, thanks dao!
Attachment #289408 - Flags: review?(sspitzer) → review+
(Assignee)

Updated

10 years ago
Keywords: checkin-needed
Assignee: sspitzer → dao
Status: ASSIGNED → NEW
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
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Firefox 3 M11 → Firefox 3 M10
Flags: in-litmus?
>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.
Depends on: 405078

Comment 34

10 years ago
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.
Flags: in-litmus? → in-litmus+

Comment 38

10 years ago
(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?
(Reporter)

Comment 39

10 years ago
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.

Updated

10 years ago
Duplicate of this bug: 425101
Product: Firefox → Toolkit
Duplicate of this bug: 315448
You need to log in before you can comment on or make changes to this bug.