Closed Bug 334767 Opened 18 years ago Closed 8 years ago

don't show restart now or later dialog after automatic background download

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
1.8 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: beltzner, Unassigned)

References

Details

(Keywords: polish)

If app.update.enabled=true, and if the update will not break any installed extensions or themes (ie: there is no reason for a user to not apply the patch) Firefox should silently download and install the update without interfering with the user's taskflow. Currently, once the update is downloaded, we inform the user and ask them to restart now or restart later; this is jarring and confusing, as they user isn't aware that the download ever happened, and since we don't guarantee to restart the browser in the same state (see bug 311744) it's almost certain that they'll click "Later" or end up frustrated. So we just shouldn't ask. If the update was fetched without any direct user action, then we should not show the "Update downloaded, restart now?" dialog at all, and instead just apply the update when the user restarts their browser. Some predicted gotchas: what happens for nightlies, where multiple updates could potentially have been issued during a single session? Do we cache the updates and apply them sequentially? STR: 1. Run a Bon Echo nightly that was built the day before today 2. Wait for a bit Actual: 1. A dialog will appear informing you that the latest Bon Echo update has been downloaded and is ready to install, Restart Now/Restart Later Expected: Nothing, but the next time I start my browser, it should apply the update that it silently downloaded while I was using it.
Dup of bug 316488?
(In reply to comment #0) > If app.update.enabled=true, and if the update will not break any installed > extensions or themes (ie: there is no reason for a user to not apply the > patch) Firefox should silently download and install the update without > interfering with the user's taskflow. This depends on bug 324121 then ? > ... > So we just shouldn't ask. If the update was fetched without any direct user > action, then we should not show the "Update downloaded, restart now?" dialog at > all, and instead just apply the update when the user restarts their browser. The one-time-only homepage (http://www.mozilla.com/firefox/updated) would need modification to provide some update information. There should be some notification, otherwise users will have no idea there was a trigger when an extension/theme breaks (either itself or the app). A proportion will be grumpy they never got a choice. > Some predicted gotchas: what happens for nightlies, where multiple updates > could potentially have been issued during a single session? Do we cache the > updates and apply them sequentially? The browser side of Update cannot handle multiple updates, so this isn't an issue as long as update checks are disabled when a patch is pending. Nightly users would likely want to disable this behaviour anyway (many probably already have the pref's set to "Ask me ...") so that they get prompted and can try the new candy.
*** Bug 316488 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Dup of bug 316488? I did it the other way around ;) (In reply to comment #2) > This depends on bug 324121 then ? Depends? No, not really. That bug should be fixed, sure, but I don't see how removing this dialog makes that process any worse, as this dialog doesn't let the user prevent the application of the update.
Pardon my French, but I think think is a bloody awful idea. Not that you lot will probably care, but I'm gonna say it anyway. I've presented my argument in bug #335798. Now you're saying FF will, by default, download stupid updates that I don't want *if I'm purposely testing code on an older version of FF*, and install them without informing me. Let it be known that I protested against this stupid idea!! GRR!!!
Another gotcha with this is that the minor updates do sometimes break things completely because of dumb firewalls or other quirky system issues - e.g. http://www.mozillazine.org/talkback.html?article=8220#5 The current dialog is annoying and bad though, so I'm not suggesting it doesn't need changing. But if people don't know an update is happening at all, then if things suddenly don't work, they will be even more clueless as to why (of course they won't ever get the one-time page about the update, because that requires that it has been successful)
There is another cause for doing it silently. If an user is typing some text and the dialog pops up it steals the focus and gets the keys the user is currently typing. If the user pressed ENTER before he/she noticed the dialog has appeared FF may go down and his/her work is lost. Personally i prefer the question if the update should be applied at next startup. So the user has still the choice to say "no".
Well, there's a million ways to avoid that particular problem. Having the dialog only appear on closing or on opening Firefox would seem the most obvious one. Or, having an icon that appeared, maybe more prominently than the previous one, when an update is available.
Flags: blocking-firefox2?
Keywords: polish
taking, I'll drive this one and try to find someone to help with a patch
Status: NEW → ASSIGNED
Assignee: nobody → beltzner
Status: ASSIGNED → NEW
Please don't.
Flags: blocking-firefox2? → blocking-firefox2+
As I've said elsewhere, in bugs that keep getting closed, this is a horrible idea. The current behavior _pisses_people_off_ because they feel like they are being treated like children--"We know what's best for you". They feel that way because we ARE treating them that way, and prettying up the interface is NOT going to make it any better. It might help by increasing the number of people who don't notice (which has its own set of problems), but those who do notice will be ENRAGED that we're being sneaky. I am not exaggerating, the lack of control induces severe RAGE in alert control freaks -- namely people like us. Grandma isn't going to notice or care if you make this change, but Grandma wouldn't have Firefox on her computer if her grandson hadn't put it there -- and *he* is going to be pissed by this feature. Pissing off your core fanbase is suicide. Treat people like adults. Not "we know best", but "this is best and here's why". Make upgrading the default path for Grandma, but give them links to persuasive information so they can trust our judgement and give them a way to opt out. Nag them if you want (replace the start page with a "you need to upgrade" page until they do? Flashing red button or toolbar?), but put *them* in control. It is *their* computer, we should not act as if we owned it. *best* case these angry people turn off the update feature (not good), but at some point people stop recommending a product that disrepects them (worse) and stop using it themselves (much worse).
I've just noticed yet another reason why this behaviour is a bad idea. My mum's computer just updated Firefox on restart. ZoneAlarm then popped up, saying "ALERT - CHANGED PROGRAM. Do you want to allow Firefox to access the Internet? The program has changed since the last time it ran!" I wouldn't blame people for clicking No to that. Whenever Firefox updates like this, the binary will change, and millions of executable binary-checking firewalls will complain about it. You haven't told the user that an update is about to occur, so how do they know that the program isn't not a trojan or virus? For that matter, how am I supposed to know? Another problem with silent updates is that it means people who may be purposely wanting to test with an older version of Firefox have absolutely no way to prevent the update from going in. At least with the current system, we can click 'Update later', then go into the Firefox binary's directory and delete some files to stop the update. Yes, this assumes we forgot to go into options and unckeck automatic updates for Firefox, but that happens aoccasionally when you're working on lots of computers. In a nutshell; Silent updates are a BAD IDEA. DO NOT IMPLEMENT THEM. WONTFIX THIS BUG.
(In reply to comment #12) > Whenever Firefox updates like this, the binary will change, and millions of > executable binary-checking firewalls will complain about it. You haven't told > the user that an update is about to occur, so how do they know that the This is a good point, though fwiw if the user does get updated definitions from their firewall vendor they'll be prepared for the binary update since we contact those vendors ahead of time and give them the new signatures. See bug 335289 for a related problem. Still, we can't expect users to have updated their firewall apps (since in many cases that's a for-pay service) and some advance indication is needed. Point taken. > Another problem with silent updates is that it means people who may be > purposely wanting to test with an older version of Firefox have absolutely no > way to prevent the update from going in. At least with the current system, we Of course they do: Options/Preferences > Advanced > Updates > uncheck automatically update > options and unckeck automatic updates for Firefox, but that happens > occasionally when you're working on lots of computers. Let me be perfectly clear: the majority of Firefox's audience are *not* testers looking to use an older version of Firefox. We are *not* going to optimize our default preferences for that audience, period. > In a nutshell; Silent updates are a BAD IDEA. DO NOT IMPLEMENT THEM. WONTFIX > THIS BUG. You do your own sensible arguments discredit by raving in all caps, Jeremy. Even given your point above, the purpose of this bug is to remove the notification from popping up immediately after the automatic download is completed since it a) steals focus, b) assumes that users will want to stop what they're doing and restart immediately, which I think is wrong in the case where they didn't explicitly ask for the update. Fixing this bug does not mean that there will be no notification at all of a pending update, just that the current mechanism isn't optimal. If you'd like to continue to (rationally, using proper capitalization) discuss alternatives, I'm all ears. Personally, I think the better time to alert a user of an update is on startup. If we see an update is pending, we then notify the user and allow a "Later" option. Further, should the user then go into options and disable the automatic downloading of an update, we can provide some UI in there for clearing any pending updates. But that would be a separate bug, or perhaps a re-opening of bug 335798.
Whiteboard: [swag: 1d for design]
> > Whenever Firefox updates like this, the binary will change, and millions of > > executable binary-checking firewalls will complain about it.ow that the > > This is a good point, though fwiw if the user does get updated definitions > from their firewall vendor they'll be prepared for the binary update There are two types of binary-checking firewalls. Whitelist-based ones like Norton Internet Security will likely be OK (as long as your subscription is valid, which may not be a good assumption given the popularity of trial versions pre-installed on new machines). Ones that don't have a service behind it like ZoneAlarm are wholly based on permissions the user has granted locally. They have no way to tell a vendor-supplied change from a infection -- all they know is change happened, they figure the user will know if they upgraded that app so they ask. > Fixing this bug does not mean that there will be no notification at all of a > pending update, just that the current mechanism isn't optimal. Yay, thanks for clarifying that. I'm totally on board with points a) and b) and not optimizing for testers. > Personally, I think the better time to alert a user of an update is on > startup. If we see an update is pending, we then notify the user and allow > a "Later" option. As long as that Later option is there this satisfies all my objections to both the current 1.5 behavior and what I thought you were proposing (totally silent forced change).
(In reply to comment #13) > > Still, we can't expect users to have updated their firewall apps (since in many > cases that's a for-pay service) and some advance indication is needed. Point > taken. > > > Another problem with silent updates is that it means people who may be > > purposely wanting to test with an older version of Firefox have absolutely no > > way to prevent the update from going in. At least with the current system, we > > Of course they do: > Options/Preferences > Advanced > Updates > uncheck automatically update > > > options and unckeck automatic updates for Firefox, but that happens > > occasionally when you're working on lots of computers. > > Let me be perfectly clear: the majority of Firefox's audience are *not* testers > looking to use an older version of Firefox. We are *not* going to optimize our > default preferences for that audience, period. I'm going to have to disagree with your apparent definition of optimizing. I don't think I'm asking you to 'optimize' for my kind at all. Doing that would involve giving technical information about the update each time there was one, and giving me the link to download the update. Clearly I wasn't asking for that; what I was asking for was _some_ way for people like me to cancel the upgrade, whilst still optimizing for 'most users'. > > > In a nutshell; Silent updates are a BAD IDEA. DO NOT IMPLEMENT THEM. WONTFIX > > THIS BUG. > > You do your own sensible arguments discredit by raving in all caps, Jeremy. Ouch, broke an eggshell there. ;-) Sorry, I guess I am rather forward sometimes but I mean no offence. > Fixing this bug does not mean that there will be no notification at all of a > pending update, just that the current mechanism isn't optimal. Ah, but I thought that that was _exactly_ the suggestion for the bugfix, which is partially why I felt so strongly. Quoth the poster: " So we just shouldn't ask. If the update was fetched without any direct user action, then we should not show the "Update downloaded, restart now?" dialog at all, and instead just apply the update when the user restarts their browser. " > Personally, I think the better time to alert a user of an update is on startup. Agreed. > If we see an update is pending, we then notify the user and allow a "Later" > option. Further, should the user then go into options and disable the automatic > downloading of an update, we can provide some UI in there for clearing any > pending updates. Such as, in the 'Update History' dialog, having listed updates that haven't yet been applied, their Status set to 'Not yet installed', and a button saying something like 'Don't install'? I'd suggest that, until the user has clicked this button on all updates that aren't yet installed, the update dialog pops up on each restart of Firefox, but I'm guessing many would say that's "too naggy". Nevertheless, if it was done that way, the Don't install button would delete the update files, stopping the nagging, although presumably the 'check for Firefox updates' box would have to be deselected too or FF would just check again and start nagging about the same update. Still, that would be logical behaviour to my mind. :-) > But that would be a separate bug, or perhaps a re-opening of > bug 335798. I'd be fine with something like the above solution. And it would effectively hide the ability not to install the update at all (although not to install it later) from 'msot users'. (In reply to comment #14) > Yay, thanks for clarifying that. I'm totally on board with points a) and b) and > not optimizing for testers. Again, I'd be interested to know why you thought the suggestion was being made to 'optimize for testers'. I really don't see my requests as optimizing, just proving an option. Many have suggested forcing upgrades down a user's throat, medicine-style. Whilst I understand the desire for online security, I just don't think mature software should be (or indeed needs to be) quite so forward.
--> nobody@mozilla.org so mconnor can get someone to implement this. I'll continue to track pending update notification in bug 335798, which I've re-opened.
Assignee: beltzner → nobody
Whiteboard: [swag: 1d for design] → [swag: 1d for design] 181b1+
Depends on: 335798
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
Whiteboard: [swag: 1d for design] 181b1+ → [swag: 1d for design] 181b1+ [mustfix]
I'm weeping as I do this, but we won't block Firefox 2 for this. A boo-hoo-hoo.
Flags: blocking-firefox2+ → blocking-firefox2-
Target Milestone: Firefox 2 beta2 → Firefox 3 alpha1
Roll on Firefox 3, eh? Looks like that's gonna be where the CSS compliance is fixed properly as well. :-\
> Roll on Firefox 3, eh? Looks like that's gonna be where the CSS compliance is > fixed properly as well. :-\ That's always been the plan, the whole reason Firefox 2 was built off the Gecko 1.8 branch instead of Gecko 1.9. CSS rendering is part of that "Gecko" bit. You might see some .0.1 bug fixes, but not large changes.
Taking, along with bug 335798. 335798 will provide a startup dialog to install (or not) the pending app update. So the question here, then, is what (if anything) to show the user when an update is available. And perhaps if an update is pending/delayed. The basic problem is that we want to avoid popping up a dialog at a random time, because the user may be in the midst of typing something. The suggestions I see are to junk the popup dialog, and perhaps add an information bar. I'd guess that most users restart their browser regularly [crashes are a feature here ;-)]. Thus, there's no need to alert the user that an update is available because they'll restart it in the next day or three anyway -- at which point 335798 can prompt them to install the update. [Hmm, do we have any talkback data that says what the average browser uptime is?] Still, one might be concerned about the small (?) set of users that run their browsers for a long period of time, and might thus be unknowingly surfing with an unsafe browser version for an extended period. [Also users who habitually click "don't upgrade now".] We might be able to use the existing app.update.nagTimer pref to silently give users a day or two to restart on their own, and then start alerting them somehow about an update. I'm a little concerned about using an infobar, because I've already seen some sites spoofing the bar in their page. Teaching users that it's important to click on the top yellow bar for critical browser updates may not be such a good idea. But the only other idea that readily comes to mind is the popup dialog, perhaps with a delay to only show it when the system has been idle for N minutes. [Which would be a pain to do XP]. So... My current thinking is to either nuke the popup entirely (and leave an open bug for the edge cases), or retask the nagTimer so the popups are only an issue for N% of the M users who don't restart regularly. Comments?
Status: NEW → ASSIGNED
from http://talkback-public.mozilla.org/reports/firefox/ click the branch/trunk/release you care about and select a simple report: http://talkback-public.mozilla.org/reports/firefox/FF2x/simple-crash-analysis.all Total blackboxes in this sample: 3174 Total unique users: 694 MTBF For these builds is estimated at 1.774545 hours, based on 3174 reports and 5632.404722 hours of user testing from testers that have crashed and reported problems. (dev. builds tend to have low MTBF) Note that not many people use unreleased nightlies especially of bonecho, perhaps a better measure is: http://talkback-public.mozilla.org/reports/firefox/FF1504/simple-crash-analysis.all Total blackboxes in this sample: 32131 Total unique users: 22312 MTBF For these builds is estimated at 39.360269 hours, based on 32131 reports and 1264684.793889 hours of user testing from testers that have crashed and reported problems. (dev. builds tend to have low MTBF) And keep in mind that last caveat about only people who actually *crash*. so, average uptime for ff1504 was slightly longer than 1 1/2 days although that doesn't say anything about people who don't crash.
(In reply to comment #20) > Taking, along with bug 335798. > > 335798 will provide a startup dialog to install (or not) the pending app > update. So the question here, then, is what (if anything) to show the user when > an update is available. And perhaps if an update is pending/delayed. I think if you're gonna have a startup dialog, you don't need anything else. I guess you could pop up an infobar immediately (why wait days?) after the update has been downloaded and is available, allowing the user to install now if they want. I guess sites could spoof the infobar, but they can do that already with things like 'a popup has been blocked'; I wouldn't worry about that. Potential spoofing of the infobar should be a separate bug. In fact, I hadn't thought of that - the infobar's location makes it quite prone to spoofing. Maybe it should appear at the top of the Firefox window. *goes off and searches for bug*.
OK, well from the looks of bug #252257, this problem has already been discussed and the general feeling seems to be that it's OK because infobar messages currently won't (and shouldn't be able to) do any real harm like installing stuff directly. So it wouldn't be an appropriate way to inform a user of a pending update. How about bringing back the 'up arrow' icon as seen in Firefox 1.0 (http://www.firefox-browser.de/MediaWiki/images/e/ea/Update.gif) for when the update's available; pop up the dialog on restart?
(In reply to comment #20) > So... My current thinking is to either nuke the popup entirely (and leave an > open bug for the edge cases), or retask the nagTimer so the popups are only an > issue for N% of the M users who don't restart regularly. Comments? > The existing dialogue would be OK if it didn't pop up in front of the browser window. Could it be made to appear behind the current window (pop-under stylée)? The user would then be prompted upon closing the current window (assuming they don't use File > Exit), and they could actively choose to switch to the pop-up window and deal with the update at any time.
(In reply to comment #21) > MTBF For these builds is estimated at 39.360269 hours, based on 32131 reports > and 1264684.793889 hours of user testing from testers that have crashed and > reported problems. Is Talkback measuring the time since the last restart, or the cumulative time since the last crash? It looks like the latter to me, so I guess the figure isn't all that useful. [And if crashes don't roughly approximate a random sample, the data is even more useless. Oh well.] (In reply to comment #23) > How about bringing back the 'up arrow' icon as seen in Firefox 1.0 I believe that was removed because it was so easily overlooked as to be invisible. (In reply to comment #24) > Could it be made to appear behind the current window (pop-under > stylée)? Hmm, I suppose that would be a simple tweak, although there's clearly a visibility issue. A perhaps a stigma associated with pop-under ads. :-) Beltzner?
(In reply to comment #25) > (In reply to comment #23) > > How about bringing back the 'up arrow' icon as seen in Firefox 1.0 > > I believe that was removed because it was so easily overlooked as to be > invisible. Well I noticed it. But as this is only intended to be a soft notification until such a time as the user restarts their browser, and rather unnecessary at all, it seems appropriate.
*** Bug 346560 has been marked as a duplicate of this bug. ***
There's also the problem of users who cannot update because they don't have write access to the install dir. It would be nice if there was some way to tell these people "you're at risk, go bug your sysadmin". This is mostly a different problem, but I bring it up because if you're going to have an infobar or bring back the "christmas tree" (update arrow icon) it may be able to serve both purposes. If you use just a simple icon without the explanatory text that could go in an infobar then it really ought to pulse to attract attention.
Blocks: 346795
Thanks for taking this, Justin. The popup should only be shown if the Software Update wizard has already been launched. In the default case, where a minor update is detected, determined to be compatible with installed add-ons and then automatically and silently downloaded, the popup should not be shown at all, and the user will be informed (by your work in bug 335798) the next time they start up their browser. If at any point the user asks to "Check for Updates ..." or if an update is detected that isn't compatible with installed add-ons, or if an update is a major update, then the Software Update wizard will be launched at some earlier point in the process and this dialog is the logical and natural end point to that wizard, so it should be shown. The existing keybuffer timeout can be used to prevent accidental clickthrough. Also, as long as we're mucking with the dialog, let's update some of these strings so that they're a little softer, removing some of the imperative commands: from /locales/en-US/chrome/mozapps/update/updates.dtd, with the appropriate entity-name-revving: <!ENTITY finishedUpdate.title "Update Downloaded"> <!ENTITY finishedUpdate.intro "The update was successfully downloaded and verified. It will be installed when you restart &brandShortName;."> <!ENTITY finishedBgUpdate.title "Update Ready to Install"> <!ENTITY finishedBgUpdate.intro "&brandShortName; has downloaded and verified an important update. It will be installed when you restart &brandShortName;. Click on the link below for more details about this update."> <!ENTITY finishedUpdate.instruction1 "Click Restart &brandShortName; Now to install the update now. &brandShortName; will restore your tabs and windows when it restarts."> <!ENTITY finishedUpdate.instruction2 "Click Later to continue working and have &brandShortName install the update the next time it starts.">
(In reply to comment #29) > Thanks for taking this, Justin. > > The popup should only be shown if the Software Update wizard has already been > launched. In the default case, where a minor update is detected, determined to > be compatible with installed add-ons and then automatically and silently > downloaded, the popup should not be shown at all, and the user will be informed > (by your work in bug 335798) the next time they start up their browser. > Are you still saying there will be updates downloaded and applied to the browser that the user won't have any ability to opt out of? I thought we had agreed that this wasn't good and wouldn't happen.
(In reply to comment #30) > Are you still saying there will be updates downloaded and applied to the > browser that the user won't have any ability to opt out of? I thought we had > agreed that this wasn't good and wouldn't happen. No, Jeremy, that's not what I'm saying at all. This bug is saying that, by default, minor updates that don't have incompatability problems with add ons will be downloaded and made ready for installation on the next update. This bug depends on bug 335798 which calls for a confirmation dialog that allows a user to opt not to install an update. Alles ist klar?
Hübsch viel, ja. What confused me a bit is your saying "The popup should only be shown if the Software Update wizard has already been launched." What popup is this? If you mean the 'check for updates' dialog, that's not the same dialog as the one that currently pops up informing users of an automatic update, and it's not really a popup anyway as the user requested it.
(In reply to comment #28) > There's also the problem of users who cannot update because they don't have > write access to the install dir. open bug, decision on how to integrate in UI (In reply to comment #29) > The popup should only be shown if the Software Update wizard has already been > launched. I'm not sure what you mean here... Are you talking about if the user clicks Help -> Check For Updates...? Currently, if we find an update then the next page in the wizard shows the download progress. The final wizard page is the restart now/later choice. I think this case can basically stay unchanged. > In the default case, where a minor update is detected, determined to > be compatible with installed add-ons and then automatically and silently > downloaded, the popup should not be shown at all, and the user will be informed > (by your work in bug 335798) the next time they start up their browser. Right, that's the goal. However, shouldn't we still be concerned about users with long-running browsers? If a critical security update comes out (eg, the WMF bug), we don't want the user being unknowingly exposed for a long time. I'm still thinking that the delay I mentioned in comment #20 would work well. Give users X days to restart on their own (and then prompt to install during the restart). Otherwise nag them on day X+1. Ideally this would eliminate most of this bug's impact, because most users would simply never see the popup. [Although lacking firm uptime data, I'm just guessing.] I'd still like to completely squash the bug by fixing the popup -- eg change it to an info bar, or maybe only trigger it when the user goes to a different URL. Does this seem reasonable?
Assignee: nobody → justin-bugzilla
Status: ASSIGNED → NEW
Just in case anyone accuses me of double posting, I am not Justin Dolske, (s)he just completely ignored my post.
(In reply to comment #33) > I'd still like to > completely squash the bug by fixing the popup -- eg change it to an info bar, > or maybe only trigger it when the user goes to a different URL. Does this seem > reasonable? Unfortunately, no, as the current concensus is that infobars should not encourage any behaviour that might cause harm because they can be faked. If you have a popup blocked warning, the user isnt expecting to have to click 'Install', 'Run, or 'Save', or something, at a later date. With the update notification, they may expect that, which would provide an opportunity for malicious code to execute.
(In reply to comment #34) > Just in case anyone accuses me of double posting, I am not Justin Dolske, (s)he > just completely ignored my post. Sorry, was there a specific comment you were expecting me to reply to? I didn't see anything directed to me, or that I had anything to add to... /me is a he. ;-) (In reply to comment #35) > Unfortunately, no, as the current concensus is that infobars should not > encourage any behaviour that might cause harm because they can be faked. Agreed. One part of my brain just decided to throw that out as an example of doing something to fix the popup problem. (In reply to comment #33) > > There's also the problem of users who cannot update because they don't have > > write access to the install dir. > > open bug, decision on how to integrate in UI Doh, forgot to fill in my non-draft comment here! That's probably an issue for another bug... UI-wise, we should make sure we handle update errors (including this specific case) in a meaningful way. I suppose we could also explicitly test for this before offering the update, but it would still have to be handled during the update. I don't think the proposed changes in this bug would have any problem incorporating this issue.
(In reply to comment #29) > from /locales/en-US/chrome/mozapps/update/updates.dtd, with the appropriate > entity-name-revving: I ended up splitting this off to bug 346795 in order to get it in for Firefox 2.
No longer blocks: 346795
(In reply to comment #13) >the purpose of this bug is to remove the >notification from popping up immediately after the automatic download is >completed since it a) steals focus,... (In reply to comment #20) > The basic problem is that we want to avoid popping up a dialog at a random > time, because the user may be in the midst of typing something. The easiest way to fix the worst of this in a hurry is to reset the focus. I'm looking at the dialog right now, and the Restart Firefox Now button has focus. Give the focus to ANYTHING except that button. And don't wait until version 3. Do I need to file a separate bug report so it can get fixed within a reasonable time? Speaking of people who don't want to update because something might break, don't forget about bug 335289.
(In reply to comment #38) > (In reply to comment #13) > >the purpose of this bug is to remove the > >notification from popping up immediately after the automatic download is > >completed since it a) steals focus,... > > (In reply to comment #20) > > The basic problem is that we want to avoid popping up a dialog at a random > > time, because the user may be in the midst of typing something. > > The easiest way to fix the worst of this in a hurry is to reset the focus. I'm > looking at the dialog right now, and the Restart Firefox Now button has focus. > Give the focus to ANYTHING except that button. > > And don't wait until version 3. Do I need to file a separate bug report so it > can get fixed within a reasonable time? > > Speaking of people who don't want to update because something might break, > don't forget about bug 335289. > Another possibility would be to have a delay before the buttons become active, so the user will not hit "Enter" before seeing the dialog. Something needs to be done, for sure; this problem - accidentally triggering a restart while in the middle of typing something - comes up frequently on the help forums. It causes users major anguish.
Depends on: 391598
Flags: blocking-firefox3?
This bug won't block Firefox 3, as it's code on the 1.8.1 branch. I am, however, nominating it for wanted/blocking on that branch, as we're hearing some complaints about update fatigue, and most of them are directly related to the application interrupting the user flow to advertise an update. I think the best thing to do here is change our default behaviour (meaning the behaviour when the default prefs of "automatically download" are set, and when there's no extension compat problems found) so that we only prompt the user if: - they haven't restarted the browser in 24 hours or more, and - the user has let the browser sit idle for 10 minutes or more Some of that work is already done on the trunk, and we can bake it there before back porting to the branch. I've swung at this pinata before, and missed, but I'm convinced that this is the right behaviour. I respect the opinions and contributions of people who've disagreed in this bug, but the fact is that the majority of users are more upset about being interrupted and having to restart than about getting an update.
Flags: wanted1.8.1.x?
Flags: blocking1.8.1.12?
Flags: blocking-firefox3?
Flags: blocking-firefox3-
http://digg.com/software/StormCenter_7_Pwned_by_Firefox Mildly relevant. I don't think this bug is particularly serious now that bug 323041 is fixed.
(In reply to comment #41) > Mildly relevant. I don't think this bug is particularly serious now that bug > 323041 is fixed. That's fixed on trunk, which will be used to build Firefox 3, which won't be out to help users who will encounter this with their version of Firefox 2.x over the next few months. I agree that it isn't urgent, but if we can backport code to the branches, we should look into doing that.
Flags: blocking-firefox3-
Blocks: 391598
No longer depends on: 391598
Is this a branch-only bug or are we going to wontfix this in favor of bug 391598?
No longer blocks: 391598
Depends on: 391598
Unassigning, since I'm not actually working on this. At least not yet?
Assignee: dolske → nobody
Whiteboard: [swag: 1d for design] 181b1+ [mustfix]
Target Milestone: Firefox 3 alpha1 → ---
Would be nice, but not blocking a 1.8.1.x release. Especially since an unassigned bug is not likely to grow a branch patch.
Flags: wanted1.8.1.x?
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.12?
Flags: blocking1.8.1.12-
(In reply to comment #40) > This bug won't block Firefox 3, as it's code on the 1.8.1 branch. > > I am, however, nominating it for wanted/blocking on that branch, as we're > hearing some complaints about update fatigue MikeB, This would be reasonable but only when bug #335798 is reopened and fixed in some way; ie. showing an update dialog on browser startup with some option, no matter how deprecated or small, not to install now. I think there should always be *some* way to back out before FF installs the update, in case you don't want to and haven't yet unchecked the 'automatically update...' option. It's just on principle. That bug should be a blocker for this one.
Product: Firefox → Toolkit
We went with an 8 day wait before prompting on Aurora, Beta, and Release which should alleviate this bug enough to wontfix it.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.