Closed Bug 335798 Opened 19 years ago Closed 18 years ago

Allow automatic updates to be installed at the user's convenience

Categories

(Toolkit :: Application Update, defect)

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

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.9alpha1

People

(Reporter: bugzilla, Assigned: Dolske)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 This has happened several times now; Firefox downloads an update behind your back and a dialog pops up. Thou shalt install this update, it proclaims. Your options are to restart/install now, or restart/install later. I'd like an option to install When I Choose To, and until then, Do Not Update. Before you automatically dismiss this idea because it would lead to people not updating, at least listen to my argument. I'm testing some code on an older version of FF (1.5.0.1) and *don't want* to install the update now, I want to keep this older version. I know there's options in the options dialog to stop all this updating, but the thing is that I'm working on many different machines, moving around (hotdesking), and the default options are selected on most installs, meaning I have to proactively change the update setting to stop this auto-updating. Needless to say, I sometimes forget to change this setting. By the time the 'thou shalt update' dialog pops up, it's too late - I'm not allowed to keep my older version! Argh! I want to test this code on it but now I can't. And apart from that, it might even break an extension. I don't think you should have to proactively change a setting from its default in order for Firefox *not* to force updates on you. Sure, download them, sure nag you regularly to install them, but at least offer the *option* of not installing the thing yet. What I propose is this - put a small checkbox in the corner of the update dialog, unchecked by default, worded "Do not install this update at this time (not recommended)". This would still get 99.9% of users to install the update now as they'd be pretty unlikely to check that (there's be no reason to), UNLESS there's a very specific reason; there are 2 I can think of. 1. You know that this update will break a certain extension, and want to wait until the extension is updated before updating FF. 2. You are testing an older version of FF with some code and don't want to update yet. Once again, I know there are settings in the options dialog for this but I still think this checkbox (unchecked by default!!!) is warranted. It will make virtually no difference on most users' updating, but will mean people like me don't have to if we don't want to update, and forget to change the update settings in the Options box until the update dialog pops up and it's too late! Reproducible: Always
Maybe this would be a good idea indeed, this to prevent upset and angry users who didn't know about the settings in the Advanced tab and are now confronted with something that seems irreversible. I think you can still make the update undone by deleting the folder updates in your Mozilla Firefox folder with Firefox still open. And it is also always wise to make a regular copy of your profile folder.
Ria, You can do that to stop the update, but I think you'd agree that that's too much of a hack to have to go to to stop the update, as well as making a regular backup of your profile folder(s).
It is strange that this dialog doesn't give you a way to opt out of the update, but I think that's intentional -- we were worried that even something like what you suggest would keep a large number of users from upgrading. Perhaps the solution is to let you cancel a pending update from the Options window.
There is some earlier discussion of default update settings in bug 310698 and bug 316725.
(In reply to comment #3) > It is strange that this dialog doesn't give you a way to opt out of the update, > but I think that's intentional The current situation is broken, annoys lots of people and needs a redesign. If the current options are intentional the "Later" button should be more honest and include the word "Install" in it, otherwise many users reasonably assume it's a "go away" button. They've been trained to expect yes/no OK/Cancel options, not to choose between yes and yes-in-a-bit. This is a dupe of whatever bug tracks the dialog reworking though. Look for a software update bug with lots of dupes on it.
(In reply to comment #0) > I'd like an option to install When I Choose To, and until then, Do Not Update. We're intentionally and purposefully not offering that option. If we push a security and stability update, then we want you to have it, and we don't want to make it easy at all for you to not have it. If you're someone with a reason not to have it (ie: a tester, or someone in a corporate deployment) then there are well-established preferences which you or your system administrator can twiddle such that it never comes down in the first place. > Before you automatically dismiss this idea because it would lead to people not > updating, at least listen to my argument. I did :) > I don't think you should have to proactively change a setting from its default > in order for Firefox *not* to force updates on you. Sure, download them, sure > nag you regularly to install them, but at least offer the *option* of not > installing the thing yet. bsmedberg filed bug 336267 which asks that if the user changes this pref after an automatic update has been pulled, it should remove the pending update; that seems like a decent solution for testers who've forgotten to set it before the update is retrieved. > What I propose is this - put a small checkbox in the corner of the update > dialog, unchecked by default, worded "Do not install this update at this time > (not recommended)". This would still get 99.9% of users to install the update Heh, in general, UI should never exist for something that 99.9% of users don't need. I'm not trying to say that we don't care about our testers, just that we're not going to care about them in a way that makes a dialog any littlest bit more confusing than it needs to be. In fact, we're looking to remove this dialog outright for the automatic download scenario (see bug 334767).
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
*** Bug 336566 has been marked as a duplicate of this bug. ***
Timing of when to perform the update also needs to be a consideration... take this use case for example... I was halfway through a long email from Yahoo to my lecturer at University concerning my course, illness, and problems I am having when my browser decided to update itself, closing my Yahoo window. I have lost all the data I was working with and now have to retype it. Thanks a bunch! I hope the idiot responsible for coding that "update" has a similar experience soon. I'm going back to IE - your system is inefficient and short sighted! (Why didn't it ASK me if I wanted to update?). Disgusted, angry, and tired! Darren Phillips (UK)
(In reply to comment #8) > Timing of when to perform the update also needs to be a consideration... take > this use case for example... I think this is more a problem with people watching the keyboard rather than the screen when they are typing, and inadvertently agreeing to "Restart Now". The 2 second delay in making that button active (introduced by bug 311288) doesn't seem to help for all these users. Bug 334767 is another aproach to this problem: not showing an update dialog at all for an automatic update download, and just applying the update when the user next restarts <toolkit app>.
*** Bug 336566 has been marked as a duplicate of this bug. ***
Reopening as per bug 334767 comment 13. Proposed solution coming up shortly.
Status: RESOLVED → UNCONFIRMED
Flags: blocking-firefox2?
Resolution: WONTFIX → ---
So here's what I'm thinking of for this one, Jeremy and dveditz, I'd be interested to hear your thoughts. - keep all the current default settings the same - don't show the "restart now" dialog unless user asked for update (bug 334767) - once update has been applied, pop infobar saying: | Firefox has been updated. (Read Release Notes) (Undo This Update) (X)| Clicking "Undo This Update" would pop a dialog that explained why the update wasn't harmful, and why only testers or users who are experiencing problems should undo the update. If the user still goes ahead with the undo, we would - issue a rollback request to the updater (need to find out if this is hard) - change the user's pref to be "Ask me what I want to do" for discovered updates - restart the browser If we had a full update, we'd probably have to insert some logic to go and get the previous full version and restore that. Tricky, but do-able. This is probably a bugmorph, but I wanted to counter-propose it as a solution that I think meets both of our goals which are: 1) allow a way for people who get upset at auto-updating software to get back to their pristine un-updated condition and change the default pref, and 2) let users who don't care automatically update.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mike, I agree about not showing the "restart now" dialog unless user asked for the update. 'Undo this update' sounds pretty close to 'Don't install this update' to me. Whilst I'd like the latter to be included in a pre-update dialog, you didn't seem to think it was acceptable in bug #334767 comment #13 because it might encourage some users not to update, even if you hide it away and make it difficult to click. Unfortunately, I think 'Undo this update' would be even more confusing to users. Why would you want to undo an update you've just installed?, they'd think. And even I'd have trouble explaining why to them, when you could just not have installed it in the first place. I think a 'dont install' beforehand is significantly more intuative than a 'reverse the install' afterwards. Also, as you hinted at in your proposed solution, 'undoing' an update might well be tricky and quite a bit harder than just not installing one in the first place. > This is probably a bugmorph, but I wanted to counter-propose it as a solution > that I think meets both of our goals which are: 1) allow a way for people who > get upset at auto-updating software to get back to their pristine un-updated > condition and change the default pref, and 2) let users who don't care > automatically update. I can understand and appreciate that you want to do that, but I'd like to try and persuade you again that the best way to do it would be to use a dialog beforehand making it very easy to update and very difficult to postpone/cancel. :-) I'd propose a dialog on startup telling the user the update is about to be installed, giving an option to read its release notes, and an 'Install update' button. Have an 'Advanced' tab that is top-right aligned, that displays "why the update [isn't] harmful, and why only testers or users who are experiencing problems should [not install] the update", with a 'Dont install' button at the bottom. The tab would also explain that if the 'Dont install' button is clicked, the user will be prompted to install that update the next time they start Firefox. When clicked, it would not install the update but would leave it as pending, similarly prompting the user to update upon the next Firefox restart unless they went and unchecked 'automatically check for updates to Firefox' during that session, in which case neither update dialogs nor updates would happen. I think this would both be more intuative than your proposed solution, and would actually result in even fewer users not installing the updates.
Mike, Just an additional thought. I can see your proposed solution is trying to bug the user less when an update is installed, by only providing an infobar notification rather than a dialog. However, I think their browsing will be significantly bugged by an update either way, because presumably you'll have to have a progress dialog before the update is auto applied with 'applying update...' as not all updates can be applied with lightning-quick speed. If you're going to have such a dialog and show something to the user before they begin their browsing session anyway, you might as well have my proposed confirmation dialog beforehand.
One problem I can see with the infobar approach is that problems from the update may not be apparent immediately, and once you dismiss the infobar you would have no way to revert. So then you start thinking about adding UI to start a rollback (buried somewhere in the options ?), and the job is getting bigger and bigger by the second. Especially when there is no existing mechanism to do those rollbacks - the best we have currently would be to send a complete update for a previous build, which requires that AUS be taught to provide downgrades as well. Without wanting to further muddy the waters, a third way to do this is to take a leaf out of what Windows Update does. Just ask the user when they first install Firefox (and when there are significant changes to the updater that require them to decide again). Set the default to automatically update, and if this is accepted don't prompt on update as planned in the other bugs (but do notify after the update). Then you have consulted the user, while pointing them in the right direction, and deal with the the underlying issue here - that a significant minority of users really dislike software doing things "behind their back".
Nick, Nah, I think it should prompt every time. Otherwise you're out of luck on a machine where you didn't install Firefox.
> | Firefox has been updated. (Read Release Notes) (Undo This Update) (X)| I'm OK with that, though I'm surprised you're OK with such a prominent "Undo" choice. I suspect it's far, far easier to catch the install before it has actually happened than to try to undo one. What are the reasons you don't want to do: | A critical Firefox update has been downloaded and will be applied at next restart (Release Notes) (Options) (X)| Where Options takes you to the pref dialog where people can set it to "Ask" or "Off" (either of which will -offer- to cancel a pending update but explain that we only do critical updates this way, not major changes). Or change Options into (More info), or even combine the two, which explains the update mechanism, offers the release notes, and only there links to Options or your Undo. > - restart the browser If we go this "Undo" route we should ask before restarting. > This is probably a bugmorph, but I wanted to counter-propose it as a solution > that I think meets both of our goals which are: 1) allow a way for people who > get upset at auto-updating software to get back to their pristine un-updated > condition and change the default pref, and 2) let users who don't care > automatically update. If Undo is not that hard then I like your proposal, though I'm surprised you'd want to wave the 'Undo' flag in front of all users instead of moving it down a level. I'm pretty sure the updates are staged into a separate directory first and only applied when the staging goes perfectly (or maybe that's only patch updates). Wouldn't be at all hard for the update process to copy the current version into a "rollback" directory, maybe even do it by simply renaming directories which would be faster than copying. We could even keep it around a while and let people rollback a week later if it takes them some time to find out they can't live with some regression.
(In reply to comment #17) > What are the reasons you don't want > to do: > > | A critical Firefox update has been downloaded and will be applied at next > restart (Release Notes) (Options) (X)| Too easy to miss. IMHO if you're going to actually update someone's software and change binary data and they haven't given their express permission (in perhaps the options dialog) for you to do so with only their passive consent, it should require their active consent (ie. click 'install').
Update undo is hard and adds changes to the update system I'm not willing to risk at this point. Besides it is not something any other update system in wide use I can think of does - so likely to be confusing. Why not: 1) Remove the "restart now" dialog as you indicated 2) Next time the browser starts prompt the user: A critical update has been downloaded would you like to: install now(default) later [ ] Don't ask me in the future 3) After the update in installed show the info bar with release notes or just the first run page
Ah, the good old 'don't ask me again' checkbox. I'd recommend against that wording because the user doesn't have a clue what it means. What if you click that and then later, does it cancel future updates? They don't know what the effect is. That type of wording has irritated me in other apps.
(In reply to comment #17) > > | Firefox has been updated. (Read Release Notes) (Undo This Update) (X)| > > I'm OK with that, though I'm surprised you're OK with such a prominent "Undo" > choice. I suspect it's far, far easier to catch the install before it has Well, the design is based on my feeling that most people are happy to have software auto-update, and a small (but very vocal - hi, Jeremy!) minority get super-upset. So this would be informative to the majority and empowering to the minority, and have the benefit of the default action being to migrate people upwards and onwards while still giving them full control over their destiny. > | A critical Firefox update has been downloaded and will be applied at next > restart (Release Notes) (Options) (X)| What tab would this show on? I was OK with the infobar attached to the homepage since, well, it was the first page the user would see and we could expect them to understand that the bar was in context of the first run .. but this appearing on whatever-page-the-user-was-on would be truly odd. Though I really like the rest of the interaction you propose. (In reply to comment #19) > Update undo is hard and adds changes to the update system I'm not willing to > risk at this point. Besides it is not something any other update system in > wide use I can think of does - so likely to be confusing. Why not: Yeah, that was my fear. Alas! > 1) Remove the "restart now" dialog as you indicated > 2) Next time the browser starts prompt the user: > A critical update has been downloaded would you like to: > install now(default) later > > [ ] Don't ask me in the future I think better than a checkbox would be: .---------------------------------------------------------------------------. | A security update for Firefox has been downloaded and is ready to be | | installed. | | (Update Later) (Update Now) ((Always Update Without Asking)) | '---------------------------------------------------------------------------' Where the latter flips some hidden pref that bypasses this dialog in the future. This dialog should also be bypassed if a user has asked to check for software updates and clicked either (Restart Now) or (Later) in that dialog.
Gawd, it's nice to know that my contributions are so worthwhile and looked at. :-(
(In reply to comment #22) > Gawd, it's nice to know that my contributions are so worthwhile and looked at. > :-( > Your worthwhile contributions have been.
Fine. Don't know why I bother, really.
Flags: blocking-firefox2? → blocking-firefox2+
Whiteboard: 181b1+
Target Milestone: --- → Firefox 2 beta1
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
Having the update happen at the next restart as the default is a step in the right direction. That helps to avoid the problem of the dialog popping up in the middle of a long web-mail compose and the user clicks return just to get the pop-up out of their face... Its amazing the number of webmaster mails that we have gotten that talk about this data loss situation as in comment 8. Considering the use high use of the browser on webmail and form entry apps we are bound to hit a high number people involved in a long composition when we push out an update. It doesn't matter the user is in the pool of "people happy to have software auto-update" or the possibily smaller minority that "always want complete control over the update". Updating and restarting the browser in the middle of composition or editing turns out to be disastrous. Sometime in the future Firefox might know if a page with any kind of significant form entry is active and not distract the user with the update pop-up during these times, but I'm guessing that would need more looking into.
Connor, we need someone to put together a patch for the updater for this ...
Whiteboard: 181b1+ → 181b1+ [mustfix]
Not going to block on this late in the endgame. While we want to do this and bug 334767, we don't know if we have the time to do this right at this late stage, and we're not going to add risk to the update system after what happened to the 1.8.1 endgame.
Flags: blocking-firefox2+ → blocking-firefox2-
I've just done a skim through the Software (and EM) Update stuff, and this doesn't look all that difficult to do. [...as Murphy's Law sprouts a cheshire grin in the distance.] Taking, along with bug 334767. It sounds like the current proposal for this bug is to just add a dialog on startup that allows a user to "Update Now" or "Update Later". A few proposals in the form of questions: 1) Do we want to keep "automatically download and install the update" as the default pref? ["Ask me" is the alternative.] Comments here and in 334767 lead me to think that it would be better to always ask on startup by default (in such a way to encourage inexperienced users to click "now"). 2) Do we even want an option to always automatically download and install? FF1.5 has so far had 5 updates in 8 months, and FF1.0 had 7 updates in the 12 months until 1.5 was released. Is saving 1 click every few months worth the UI? Seems like a low nag-factor. The only use I can think of is for an experienced user installing Firefox on an inexperienced user's system. 3) For the startup dialog to really be useful, it ought to show which addons, if any, would be disabled by the update. I presume we should also check for currently available addon updates, and offer to update them... Reuse the existing Addons Update UI, or put a simplified version in-dialog? [Touches on bug 324121]
Status: NEW → ASSIGNED
is there a way to revert 1.5.0.x to a previous, more safe, behavior? another round of heavy complaints on webmaster today with the release of 1.5.0.5... the previously noted data loss when the update proceeded durning webmail composition and general user confusion about the loss of control... "... Hi Was that an auto update on my firefox browser or did some virus in my computer cause it? I was seconds from hitting send on a long email then browser decides to close itself (email vanishes) and feast on an update. I am sure you can make a guess at how I felt." "...Twice I have lost an e-mail that I was working for some time when you decided to ask if I wanted to up-date the browser. If this happens one time it is back to IE for me. Fix it." "...Does Firefox/Mozilla ever send messages that they need to be updated? I had a message this morning...and before i thought much about it i clicked UPDATE NOW. Now i am thinking i should have checked your website first. it looked geniune. are there automatic update messages?" "...An edition or two ago when I saw a url in an email, I could easily go to it with no trouble. Now it is the same old deal that I had with Bill Gates search engines (exclusively). Rather than improving your updates, I see a let down. I have no choice but to update, and then I cannot get some programs that I had before. I am sure you will get them later, but in the meantime.... I am not an expert by any means at this, but am curious as to what gives."
Flags: blocking1.8.0.6?
(In reply to comment #28) > It sounds like the current proposal for this bug is to just add a dialog on > startup that allows a user to "Update Now" or "Update Later". And to have added functionality in the options dialog to allow an update that's scheduled for 'later' not to be installed at all. > A few proposals in the form of questions: > > 1) Do we want to keep "automatically download and install the update" as the > default pref? ["Ask me" is the alternative.] Comments here and in 334767 lead > me to think that it would be better to always ask on startup by default (in > such a way to encourage inexperienced users to click "now"). I think a good idea would be to have 'Later' hidden in another tab in the dialog, but not highlight anything by default in case of accidental keypresses (space or enter generally == activate highlighted button). > 2) Do we even want an option to always automatically download and install? > FF1.5 has so far had 5 updates in 8 months, and FF1.0 had 7 updates in the 12 > months until 1.5 was released. Is saving 1 click every few months worth the UI? > Seems like a low nag-factor. The only use I can think of is for an experienced > user installing Firefox on an inexperienced user's system. Don't understand your point here. I don't think automatic updates are really for convenience, they're much more to do with forcing updates in inexperienced users, ostensively for 'security' (I don't think old version of FF are particularly insecure though). > 3) For the startup dialog to really be useful, it ought to show which addons, > if any, would be disabled by the update. I presume we should also check for > currently available addon updates, and offer to update them... Reuse the > existing Addons Update UI, or put a simplified version in-dialog? [Touches on > bug 324121] Yes, although the idea is that for bugfix updates (0.0.0.x), it shouldn't break, or cause to be disabled, any addons.
(In reply to comment #30) > > 2) Do we even want an option to always automatically download and install? > > Don't understand your point here. My point is that if we always ask the user before applying an update -- and that only happens every month or two when an update is released -- then it doesn't seem like there's a strong need for UI to tweak it. The default behavior is ok for most users, and having to click "Update Now" a few times a year isn't a terrible burden.
(In reply to comment #28) > A few proposals in the form of questions: > > 1) Do we want to keep "automatically download and install the update" as the > default pref? ["Ask me" is the alternative.] Comments here and in 334767 lead > me to think that it would be better to always ask on startup by default (in > such a way to encourage inexperienced users to click "now"). We'd change the wording as the pref, but automatic downloading is a big win, and a better experience for users (a lot of the anecdotal evidence is that if the update is ready to go, users are far more likely to just click "Update Now") We want users to always upgrade, the reason we're changing this somewhat is to allow users to opt out. Asking on startup is what we want, but we want the download ready to go, not start downloading while the user is waiting. > 2) Do we even want an option to always automatically download and install? > FF1.5 has so far had 5 updates in 8 months, and FF1.0 had 7 updates in the 12 > months until 1.5 was released. Is saving 1 click every few months worth the UI? > Seems like a low nag-factor. The only use I can think of is for an experienced > user installing Firefox on an inexperienced user's system. I don't think there's value in not offering this, if the behaviour is to just upgrade on startup. Its useful for deployments as well, but personally I'd just switch this on and leave it. > 3) For the startup dialog to really be useful, it ought to show which addons, > if any, would be disabled by the update. I presume we should also check for > currently available addon updates, and offer to update them... Reuse the > existing Addons Update UI, or put a simplified version in-dialog? [Touches on > bug 324121] Well, that's a more complicated question. IIRC, we don't even download if there's known incompatible extensions, which is probably what we want to maintain. I'd rather have the choice to apply be part of the updater, which is a native app and unaware of anything except files and replacing, and doing this would either require an undue amount of work, or starting the app, then killing it and starting the updater. Ideally, we've already advised the user before we get the update. It occurs to me that update checks in the browser, where incompatible extensions are running, it would be nice to have a "tell me when everything's compatible" mode, but for things like session restore, now that they're pulled into the client, that could be bad.
Assignee: nobody → justin-bugzilla
Status: ASSIGNED → NEW
(In reply to comment #28) > It sounds like the current proposal for this bug is to just add a dialog on > startup that allows a user to "Update Now" or "Update Later". As shown in comment 22, yes. (I suppose, ideally, this dialog would not be shown if the user has clicked "Restart Firefox Now" in the Software Update Wizard, but if it's hard to detect that case, then I'm willing to put up with the second confirmation.) > 1) Do we want to keep "automatically download and install the update" as the > default pref? ["Ask me" is the alternative.] Comments here and in 334767 lead > me to think that it would be better to always ask on startup by default (in > such a way to encourage inexperienced users to click "now"). As mconnor says, we'd want that pref panel to be (with shown defaults): When updates to Firefox are found: ( ) Ask me what I want to do (o) Automatically download the update [x] Warn me if the update isn't compatible with my add-ons [x] Ask me before installing the update The new checkbox (default=on) would inversely correspond to the "Always Update Without Asking" button. > 2) Do we even want an option to always automatically download and install? Yes. We want to make installing an add-on as painless as possible, and part of that experience (counter-intuitively) is not asking before fetching the update. Doing so means that -- in the default case -- by the time we're asking you about applying an update, it's already sitting on your system ready to go, and the net effect to you saying "yes, I would like to apply that update" is 10 seconds of your time. The goal is to stay out of the user's face as much as possible. > 3) For the startup dialog to really be useful, it ought to show which addons, > if any, would be disabled by the update. I presume we should also check for > currently available addon updates, and offer to update them... Reuse the > existing Addons Update UI, or put a simplified version in-dialog? [Touches on > bug 324121] By default we check for this before downloading the update, so in this case, the user would already have been alerted. Again, that's the least-obnoxious thing to do, as it ensures that we don't spend the time grabbing an update that will break our users. As Jeremy pointed out, though, we do our very best to ensure that minor updates don't break add-ons. (In reply to comment #29) > is there a way to revert 1.5.0.x to a previous, more safe, behavior? another > round of heavy complaints on webmaster today with the release of 1.5.0.5... See comment 19 for undoing updates; I'd like to support it, but apparently that's in the realm of the "very hard". While I feel the pain in all the complaints you're getting, I also see many happy faces on people who were glad to see that Firefox was keeping them safe on the web. Whenever we're around the time of an update, if I meet anyone and tell them I work on Firefox, I always hear "Oh! I just got an update from you guys. Thanks!", and never in a sarcastic way. (In reply to comment #30) > And to have added functionality in the options dialog to allow an update > that's scheduled for 'later' not to be installed at all. I think the right-est thing to do for this would be to morph bug 336267 so that the "Update History" showed a "pending" update with a button to "delete" it. Makes it possible, but certainly not obvious, which is exactly what we want. Chofmann: this is also where I'd want rollback UI, should we ever allow it. Installed updates would have a "revert" button or something if it was possible to do so. (In reply to comment #31) > My point is that if we always ask the user before applying an update -- and > that only happens every month or two when an update is released -- then it > doesn't seem like there's a strong need for UI to tweak it. The default > behavior is ok for most users, and having to click "Update Now" a few times a > year isn't a terrible burden. With my design above for two seperate prefs for "download without asking" and "update without asking" I think this point is moot; let me know if you disagree / if I'm misinterpreting you.
(In reply to comment #33) > (In reply to comment #30) > > And to have added functionality in the options dialog to allow an update > > that's scheduled for 'later' not to be installed at all. > > I think the right-est thing to do for this would be to morph bug 336267 so that > the "Update History" showed a "pending" update with a button to "delete" it. > Makes it possible, but certainly not obvious, which is exactly what we want. I suggest that when you do this, you also propose to change the wording of the 'Show &Update History' button to 'Show Installed and Pending &Updates' to make it more suitably descriptive.
> it's already sitting on your system ready to go, and the net effect to you > saying "yes, I would like to apply that update" is 10 seconds of your time If bug 307181 (apply the patch into a staging area in the background) is fixed, it won't even be 10 seconds of your time.
(In reply to comment #32) > > 1) Do we want to keep "automatically download and install the update" as the > > default pref? > > We'd change the wording as the pref I think it's more than just wording; the current default for that pref aims to make updating happen without user intervention. That's *not* what we want to happen now. Instead we want the value that maps to "always ask me." I think that's just a matter of changing the default in firefox.js. I agree with the rest. > Well, that's a more complicated question. IIRC, we don't even download if > there's known incompatible extensions, which is probably what we want to > maintain. Yes, that's the current behavour. But if we're prompting on startup now, we should have it downloaded. In principle, is there anything wrong with just always downloading the update? [I'd add a new "needsapproval" patch state to break the current assumption that a fully downloaded patch is ready to be installed.] (In reply to comment #33) > > When updates to Firefox are found: > ( ) Ask me what I want to do > (o) Automatically download the update > [x] Warn me if the update isn't compatible with my add-ons > [x] Ask me before installing the update If we just go ahead and always download the update (downloading != installing), then we could drop the two radio buttons. We really only need 3 states, although this UI is a bit too awkward: [ ] Install updates without asking me [x] Unless the update isn't compatible with my add-ons > > 2) Do we even want an option to always automatically download and install? > > Yes. We want to make installing an add-on as painless as possible, and part of > that experience (counter-intuitively) is not asking before fetching the update. I should have been clearer... I was asking if there was value in having a "automatically install without prompting" setting in the UI. Forget the part about when downloads happen. I would just as soon drop the entire UI, and "do the right thing" -- download in the background, always prompt before installing anything, and always warn the user if something is incompatible. I'm not sure how useful the alternatives are. But maybe that's too extreme of a step. :-) > Doing so means that -- in the default case -- by the time we're asking you > about applying an update, it's already sitting on your system ready to go, and > the net effect to you saying "yes, I would like to apply that update" is 10 > seconds of your time. The goal is to stay out of the user's face as much as > possible. Yes, absolutely. > I think the right-est thing to do for this would be to morph bug 336267 so that > the "Update History" showed a "pending" update with a button to "delete" it. > Makes it possible, but certainly not obvious, which is exactly what we want. Sounds reasonable. > With my design above for two seperate prefs for "download without asking" and > "update without asking" I think this point is moot; let me know if you disagree > / if I'm misinterpreting you. I think the default actions are correct, I'm just wondering about the need to make it work differently.
Target Milestone: Firefox 2 beta2 → Firefox 3 alpha1
Can't see how this kind of UI change could happen in 1.8.0.x renominating for firefox2 to reconcile with beltzner's "mustfix" in the whiteboard and the reams of angry mail we get every update.
Flags: blocking1.8.0.7?
Flags: blocking1.8.0.7-
Flags: blocking-firefox2?
Flags: blocking-firefox2-
At this point, screwing with the update system carries too much risk to block on this, especially since we don't even have a solid plan. While we want to fix this the right way, we'll have to wait for next cycle to do this. If Justin comes up with a safe and low-risk patch we can take before freeze, we can consider that, but its unlikely to happen.
Flags: blocking-firefox2? → blocking-firefox2-
Whiteboard: 181b1+ [mustfix]
Actaully the user needs to be able to decide whether or not to upgrade or not. I'm sick and tired of Firefox upgrading against my wishes. I've tried to prevent Firefox from upgrading itwelf, but I just can't stop it. Is this part of the Bush administration's illegal spy program? How do you prevent an upgrade? Open SuSE 10.0 Linux
Anyone working on this bug? I just got another godd*mn automatic update from Thunderbird, which i HAD to install (because i'd forgotton previously to uncheck the default 'check for automatic updates' option). GRRRRRRR.
Jeremy, you know better, I thought, than to spam bugs with advocacy comments... No one is currently working on this bug, and given that I'm not sure any of the existing solutions represent an improvement for 90% of users, I don't know if we actually want to fix this anymore. This is in line with how we'll handle anti-malware and other security interactions where we're removing the ability (by default) for users to ignore insecure situations. I don't believe that "don't install security fixes" is a choice we want to enable by default, by the same logic we've been using elsewhere.
We had a long discussion about this in this bug and the general decision was that it was reasonable to provide a small option somewhere to allow the user not to install the update. But, hey, go ahead and ignore it all. WONTFIX the bug if you feel so strongly about it. But I totally disagree with you.
Yes, we had a long discussion, a year ago. And if I had stepped in a time machine and jumped to now, I don't think I'd have changed my mind. But in the real world, its a year later, we're older and wiser and have more information about users and how they evaluate security choices. By taking a more agressive (and possibly controversial) stance against allowing users to make bad choices, we believe the good outweighs the bad. A "Not Now" button is a bad security choice, period. It might have other benefits, but it is never the right choice for a user who wants to keep themself as safe as possible. You're welcome to disagree completely, but since I think you're focused on the wrong things, I think that's to be expected. We do need to fix the UI around the dialog (I favour getting rid of the dialog and having an informative notification for users who want to immediately apply it). I'll file a spinoff bug to track not giving users a bogus choice, and mark this as WONTFIX.
Status: NEW → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → WONTFIX
(In reply to comment #43) > A "Not Now" button is a bad security choice, period. Jeremy was not asking for a "Not Now" button on the dialog (he's clearly been worn down by our stubbornness), he was asking for a "small" something "somewhere" to cancel a pending update. Like beltzner's proposal to morph bug 336267 (see comment 34), or even just the unmorphed bug 336267. > I'll file a spinoff bug to track not giving users a bogus choice, and > mark this as WONTFIX. Did that happen?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.