Closed Bug 319198 Opened 19 years ago Closed 14 years ago

disabling auto-update using the pref panel doesn't work

Categories

(Toolkit :: Application Update, defect)

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

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mvl, Unassigned)

References

Details

Yesterday, I disabled checking for updates in the pref panel. Today, deer park showed a popup telling me that there it downloaded update fro Deer Park 1.6a1 (didn't know that was released...)
It shouldn't have done that. It should have been silent, and not have tried to download any updates.
(used a linux nightly trunk build, 20051202, from ftp.mozilla.org)
I'm seeing this on current trunk too, I have checked about:config and shows app.update.auto as being false. Happening on Windows XP SP2 for me.
OS: Linux → All
app.update.auto is the pref that controls whether or not you are prompted before the update is downloaded. app.update.enabled controls whether or not the update service runs at all. What is the value of app.update.enabled? Does it match the state of the checkbox beside "Automatically check for updates to: brandShortName" ?
app.update.enabled does match the checkbox on prefs for me. I will set to false and see what happens with updates.
*** Bug 289579 has been marked as a duplicate of this bug. ***
This also affects Thunderbird. app.update.auto set to false and updates still download and install themselves.
Seems fixed for me on trunk.
I know that this is happening for a college from me at home with Firefox 2. If this doesn't happen with trunk anymore we should limit it to 2.0 branch.
Ian, how long has it been resolved on trunk for you?
Jerry do you still see this?
Note: reporter no longer uses nightlies
I've autoupdate switched on for months on trunk so I don't know when it got fixed on trunk.
Reporter (or anyone else), are you able to reproduce this issue? If yes, it would be really helpful to get such a broken prefs.js or even the whole profile. Without  this information we cannot do anything and have to close this bug as WFM. Thanks.
I no longer use trunk builds, so I cannot comment. I do find the idea of marking bugs as WFM without somebody actually having it work for them a bit misleading. If I were poking around Bugzilla for bugs to fix, I would assume WFM bugs were fixed ... not that the reporter didn't respond to a question. Perhaps incomplete is a better status.
(In reply to comment #11)
> Perhaps incomplete is a better status.

Indeed. But let us wait if someone has a good testcase. 


Okay, after having autoupdate switched off on trunk since 7th, I've just had trunk (UA = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011804 Minefield/3.0b3pre) download an update without being asked to.
Ian, would you share your profile or at least send it to me? I would try to reproduce the issue.
How's best to get the profile to you?
If necessary clear your private data first. Afterwards use e.g. zip to pack all the files within the profile and send this archive to this mail address. If you have further questions just drop me a mail. Thanks.
I tried once yesterday and got a bounce with following error:
    SMTP error from remote mail server after end of data:
    host gmail-smtp-in.l.google.com [66.249.93.27]:
    552 5.7.0 Illegal Attachment k30si373512ugc.53
Trying again now.
    SMTP error from remote mail server after end of data:
    host gmail-smtp-in.l.google.com [66.249.93.114]:
    552 5.7.0 Illegal Attachment 20 [details]si1127965uga.20

Failed again.
Thanks. Finally I got it. Give me some days to run a test.
Ian, after some tests within the last days I'm not able to reproduce this issue with your profile. I installed Firefox 2.0.0.1 and let it use your profile. Even after a whole day no update is automatically downloaded and applied. Seems to be a tricky issue which only happens under special conditions? Further I saw that it's not a fresh one and gets also used with Minefield meanwhile. If you can repro it on your side it shouldn't matter.
I regret to say I saw this happen on one of my machines in the last 3 days.  I immediately confirmed on software update panel that Minefield was unchecked.  xref bug 373956 (thunderbird)
Another idea I have is that another profile downloaded the update and it get applied when starting with the regular at a later time. I'll have a test tomorrow what happens if an already downloaded update is available to install but the pref is disabled.
Does anyone of you, who is able to see this bug, work with multiple profiles?

If yes, this could be the cause. If the pref for the update is enabled in another profile it starts downloading after a while. When you close Firefox while downloading and restart with the please-do-not-update profile the download is still continued and no pref check done.
Although I do not currently use trunk builds, when I saw this problem I did not have multiple profiles.
There must be a way to disable auto-update that is profile independent,
and applies to all profiles.  It's really a property of the code, not the
profile.  Since each profile does not have its own copy of the code, it 
does no good to disable auto-update for one profile, but not all profiles.
Creating a new test profile should NOT be a way of starting yet another
unwanted auto update.  

I guess one can put the host names from the update URLs into one's hosts file.
I'm not sure how effective that will be.
There isn't a way to do that from the UI, I don't believe. If you really want to prevent all updates in a multiple-profile environment then I think you'd have to do something dirty like change your update channel to something bogus.

But really, disabling auto-update is dangerous. Hopefully no one would try to do that outside of a testing scenario.
update channel is also profile content, no?
Disabling auto update is not as dangerous as having an uncontrolled set
of executables on the system.  Doing manual updates after periodic backups
is much less dangerous.
Periodic backups are great, sure, but they won't do a thing to protect you from some web exploit that steals your bank account password... Your only hope there is that you've got a security update in the pipeline.

I'm not up for arguing the pros/cons of automatic updates, but unless people reading this bug really, really know what they're doing I wouldn't pursue this any further (especially if we're talking about multiple profiles due to multiple users of Firefox on the same system, some of whom might not know what they're doing).

Anyway, the update channel is a per-app setting, not per-profile. Any value you set for it in about:config is ignored.
(In reply to comment #25)
> There must be a way to disable auto-update that is profile independent,
> and applies to all profiles.  

xref Bug 317703 – Software Update options should be system-wide, not profile specific.
Product: Firefox → Toolkit
(In reply to comment #28)
> Periodic backups are great, sure, but they won't do a thing to protect you from
> some web exploit that steals your bank account password... Your only hope there
> is that you've got a security update in the pipeline.
> 
> I'm not up for arguing the pros/cons of automatic updates, but unless people
> reading this bug really, really know what they're doing I wouldn't pursue this
> any further (especially if we're talking about multiple profiles due to
> multiple users of Firefox on the same system, some of whom might not know what
> they're doing).
> 
> Anyway, the update channel is a per-app setting, not per-profile. Any value you
> set for it in about:config is ignored.

- If the preference is ignored, it shouldn't be there.

- I'm also talking about the checkbox in the "Updates" Preferences (a bug which I reported about that was duped to another which was duped to this one).

- I'm using several Mozilla applications, and I install a new nightly (trunk nightly or branch nightly, as the case may be) for each of them when I notice that they are all available, which is usually around 13:00 UTC every day if I'm at the keyboard at that time, or whenever I come back otherwise. If one of the nightly tinderboxen is red I check whether a recent tinderbox-build is available for the same app. So if a new Suiterunner nightly is already available at 09:00, long before the other apps I use are ready, I couldn't care less. Therefore I tell all my Mozilla apps to check for extension upgrades but not for app upgrades because I check for app upgrades myself (on the FTP server and/or the Tinderbox waterfalls) at a fixed time every day, and I only do that check when logged in as root. Is that "not knowing what I'm doing"? With my workflow, popping a warning that a new nightly is available is just disrupting whatever I might be doing, and not helping me in any way.
(In reply to comment #32)
> (In reply to comment #28)

>> Anyway, the update channel is a per-app setting, not per-profile. Any 
>> value you set for it in about:config is ignored.

I think you mean it *SHOULD BE* a per app setting, not per profile.  
I agree with that.  The problem is that it is implemented as a per profile
pref.  So, you set the pref to stop updates in one profile, because you 
really don't want any updates for a while (say, you're debugging something) 
and then you use another profile and the app gets updated.

> - If the preference is ignored, it shouldn't be there.

When you set the no-update pref in your profile, and then you find that 
the app has been updated, it seems to you that your pref has been ignored,
but in fact, what has happened is that the pref from some other profile 
has been used, instead of your profile's pref.  This pref really needs to
be app-wide, not per profile.
(In reply to comment #25)

> I guess one can put the host names from the update URLs into one's hosts file.
> I'm not sure how effective that will be.

I now use that very means to stop updates in all profiles.  But it only stops
app updates, not extension updates.  Sigh.  For them, the host names used for
the extension updates must each be found and entered into the hosts file. :(
Nelson, if you'd like the ability to stop extension updates in this fashion can you please file a bug against Toolkit -> Add-ons Manager? Thanks
Robert, I'll consider that after Firefox moves first, and makes the option
to disable Firefox updates be system wide, not profile specific.  Then the
others will follow to "get in line".  Until then, others will not do that,
for fear of getting out of line.
Nelson, no problem though App Update is part of toolkit and when it changes all apps would change at the same time and the same is true for the Extension Manager.  Also, there is bug 317703 for making the app update policy either a system or user level policy which would be fairly simple using the registry on Windows but less clear on Linux and Mac OS X.
Today I started my browser (a recent hourly) and Minefield started to update (or actually must be downgrade) to the latest nightly, although the pref app.update.enabled was set to false. The reason is that I had run yesterday the same build with a new profile (with default settings) and it had downloaded its updates.
Ria, and what I believe is that the update was downloaded to a shared location (e.g. under the program folder). This downloaded package was used afterward when you started with the profile where the pref was set to false. Don't we obey this pref on startup and use it only to determine if an update has to be downloaded or not?
The code doesn't differentiate between a user initiated download vs. a background download when resuming a download on startup. The pref is obeyed as far as checking for updates in the background which can then start the download.
There have been no additional reports of the original report from 2005 so resolving -> wfm.

There have been numerous changes to the code since the original report and I am fairly certain that this bug has been fixed as it was originally reported. If anyone is still able to reproduce please file a new bug reports with steps on how to reproduce. Thanks
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.