309784 - Auto Update does not work [ensure update check and silent download happens as expected]

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050921 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050921 Firefox/1.4

Auto Update simply does not work.  I am running the 1.4 Branch with default auto
update parameters; however, whether Firefox is actually checking for updates
every 24 hours or not (as so configured) is debatable, as I never receive any
notification whatsoever that an update is available, nor does my browser build
number change after days of not updating.  I also do not get notified about
extension updates.

I can manually update my browser; however, when I click to manually "Check for
Updates...," only Firefox updates are ever found.  No extension updates are ever
found.  For those, I must separately use Extensions Manager.  My configuration
if for Firefox to "Automatically download and install the update," but "Warn me
if this will disable extensions or themes,"

To test whether it was just a problem of updates not being found because nothing
was happening at app.update.url, I modified it from
https://aus2.mozilla.org/update/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/update.xml
to the same value as app.update.url.manual (i.e.
http://www.mozilla.org/products/firefox/releases/1.4/ ) and waited another
couple of days; but still NOTHING!

I posted on Mozillazine and the respondents also acknowledged that they too were
not getting update notification.  Thus my conclusion that Auto Update is b0rk<3n
- unless Auto Update is not supposed to work unofficial builds.  In which case,
how are we supposed to know it's even working at all?


Reproducible: Always

Steps to Reproduce:
1. Make sure that all your auto update parameters are set to the default
2. Wait a couple of days to see if anything ever changes or if you ever get any
kind of notification appart from manual intervention to update the browser.
3.

Actual Results:  
Nothing happens unless I manually click "Check for Updates..." - even though my
configuration if for Firefox to "Automatically download and install the update,"
but "Warn me if this will disable extensions or themes," and all other
update-related parameters are default, which means checking for updates should
occur daily.

Expected Results:  
Firefox should automatically download and install (without manual intervention)
updates that will not disable my extensions, per my configuration, or at least
notify me about the availability of a new Branch build (and any updated extensions).

Comment 1

[Darin Fisher]

Is this a build of Firefox that you created yourself, or did you download it
from the Mozilla FTP site?  Either way, can you tell me what value you have for
the pref app.update.channel?

Comment 2

[IU]

> Is this a build of Firefox that you created yourself
I'm not competent enough to build Firefox myself. :-)

app.update.channel = nightly

Comment 3

[Ryan Flint [:rflint] (ping via IRC for reviews)]

Try setting app.update.url to
https://aus-staging.mozilla.org:8711/update2/0/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/update.xml

Comment 4

[Darin Fisher]

OK.  The same setup is working for me.  I just got a notification this morning,
from yesterday's branch nightly build, about an update for today's build.  How
many other people are seeing this?

NOTE: User-defined values for app.update.url are ignored.  It doesn't matter
what you change it to, Firefox will still use the default value.  To really
override app.update.url, you must change app.update.url.override.  So, I don't
think the problem is related to the value of app.update.url you have set. 
Moreover, if there were a problem with that value, then manual update would also
not work.

Comment 5

[IU]

I'm confused.  Ryan say to change it and Darin says it doesn't matter.  Which is
it? :-)

Comment 6

[IU]

Darin:  has yours always worked?  If not, when did if first start working?  What
build are you using?  Have you ever tweaked your update settings?  To what values?

Thanks

Comment 7

[Darin Fisher]

> Darin:  has yours always worked?  If not, when did if first start working?  What
> build are you using?  Have you ever tweaked your update settings?  To what values?

It has pretty much always worked for me.  The build I just tested was
yesterday's build updating to today's build.

Comment 8

[IU]

> It has pretty much always worked for me.

What is your app.update.url?

I'm going to change my automatic update option to "Ask me what I want to do" and
wait another 24+ hours to see what happens.  Failing that, I will uninstall
everything, install the 20050922 build and waith another 24+ hours.

I don't want to try Ryan's suggestion yet - especially if my presently
app.update.url setting (the default) should work.

It would be nice if Firefox generated a debug log.  Even JavaScript Console has
no logging capability.

Comment 9

[Brian Polidoro]

I have been having the same problem of not getting notifications about new
updates.  I'm also on WinXP.  But I did get one after a while when changing
app.update.interval to 300.  So I know the feature is not broken but is not
doing it's job in a timely manner.  

What happens if a check for an update fails to determine if an update is
available?  I'm guessing it waits another day before checking again.  Wouldn't
it be prudent to check more often if the check for an update fails? I'm
wondering if a scenario like this could be the cause.  Although I haven't had
any manual checks for updates fail.  

Comment 10

[Darin Fisher]

OK, what I think we need to do here is ensure that the update check is happening
in a timely manner, etc.  Some code audits are probably in order.

-> me

Comment 11

[IU]

OBSERVATIONS AND THEORY AS TO WHY AUTO UPDATE MIGHT BE FAILING

In the following Mozillazine post:
http://forums.mozillazine.org/viewtopic.php?p=1764942#1764942 , Littlemutt
posted that his app.update.lastUpdateTime.background-update-timer parameter was
1127584803

IMPORTANT NOTE: Littlemutt had change his update time to 300 seconds, that
morning (per his post here:
http://forums.mozillazine.org/viewtopic.php?p=1764768#1764768 )

Interestingly, I do not have that parameter in my about:config, but it is
present only in \Mozilla Firefox\components\nsUpdateService.js. There also is
non in my profile directory

I performed a recursive search from the Firefox application root for
app.update.lastUpdateTime, and the only result I got was the nsUpdateService.js
file. Further, within that file, these are the only references to
"app.update.lastUpdateTime":

*** the first number is the file line number ***
50 const PREF_APP_UPDATE_LASTUPDATETIME_FMT = "app.update.lastUpdateTime.%ID%";
2278 var preference = PREF_APP_UPDATE_LASTUPDATETIME_FMT.replace(/%ID%/, timerID);
2288 var preference = PREF_APP_UPDATE_LASTUPDATETIME_FMT.replace(/%ID%/, id);

Therefore, since I cannot find app.update.lastUpdateTime anywhere else, and with
a value, could this be the reason for the failure? That is, could it be that
because Firefox has not successfully auto updated before, a value for
app.update.lastUpdateTime is not being stored anywhere and thus the check is
failing. So then could it be that the reason auto update works when the timing
is set very aggressively (say 5 min) is that a value for
app.update.lastUpdateTime is generated, when none can be found, and held in
memory and checked against this value, but on browser shutdown, the value is
never written to disk? Thus, I am assuming that auto update will work only if
someone leaves their system and Firefox running for a duration equal to or
greater than the value of app.update.interval (the default being 24 hours),
since the app.update.lastUpdateTime value is never written to disk. I can't test
this theory with the default value because my system noise would keep me up! :-)

Note: I uninstalled and reinstalled Firefox today using the 2005092206 build to
see if the lasted builds would be picked up. Thus, this is a clean install with
no mucking aroung.

Comment 12

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Seems unlikely that app.update.lastUpdateTime has much to do with being unable
to receive new updates... Give this a try to see if it's the timer that is
getting you:

1. Set app.update.interval to something like 60 (seconds).
2. Set app.update.timer to something like 5000 (milliseconds).

That should fire an update check once every minute (as opposed to every 24
hours).  At least this way you can tell if it's a timer problem you're seeing or
something else...

Comment 13

[IU]

(In reply to comment #12)
> Seems unlikely that app.update.lastUpdateTime has much to do with being unable
> to receive new updates... Give this a try to see if it's the timer that is
> getting you:
> 
> 1. Set app.update.interval to something like 60 (seconds).
> 2. Set app.update.timer to something like 5000 (milliseconds).
> 
> That should fire an update check once every minute (as opposed to every 24
> hours).  At least this way you can tell if it's a timer problem you're seeing or
> something else...

Here are my observations:

It was only after making the changes you indicated, waiting a few minutes, and
then checking back in about:config that I finally say an entry called
app.update.lastUpdateTime.background-update-timer.  Thus, I suspect my theory
regarding that preference (Comment #11) may be true.

Furthermore, my setting is "Automatically download and install the update," but
even after several minutes I received no update.  When I clicked the Help menu,
I saw the "looping circle," for lack of a better term, and the words
"Downloading update..."  Thus, Firefox seemed to be stuck trying to get the
update.  Clicking on that entry brought up a dialog and downloading finally started.

Upon shutting down the browser, the installation was completed and the browser
restarted.  I then waited to observe whether I would get another notification. 
Receiving nothing, I checked the Help menu and saw what I described previously.
 Shortly after, I finally got a "Software Update" dialog popup indicating that
an update was available.  Another one?  Seems the prior update was only for
2005092206 to 2005092307.  I clicked "Restart Firefox Now."

This time, Firefox was updated to 2005092406 and I received an update
notification within a minute of the browser restarting.  I restarted Firefox and
the update was installed.  When Firefox was back an running, now updated to
2005092506, I waited about 5 minutes before I received the final update
notification (for 2005092607).

Thus, it appears that, in addition to the
app.update.lastUpdateTime.background-update-timer issue, there may be a problem
with auto update being able to retrieve the update from the server.  Load? 
Corruption?  Why does manual updating seem to have no issue and only auto update?

Lastly, why doesn't Firefox download all available updates in on batch?  This is
going to get very annoying for users who happened to miss several patches
because either they hadn't used their browser for a while, or they just
reinstalled their browser from a prepatched version for which several individual
patches are available.

Comment 14

[Darin Fisher]

IU, thank you for your feedback.

1. In the automatic mode, Firefox downloads the update archive very slowly. 
Only when you click on the "Downloading Update..." menu item does it kick into
high gear and attempt to download as fast as it can.

2. The batch update problem only applies to the "nightly" update channel.  Users
of 1.5b1 are on the "beta" channel, and will receive partial updates to the
latest beta.  Likewise, users of 1.5 final will be on the "release" channel, and
this problem will not affect them.  If you think about it, it would be
impractical to maintain partial updates between all nightly builds.  There's a
bug already on file about giving users a complete update to get them to the
latest nightly build.  That will probably start happening in a couple weeks once
Chase has some free time.

Comment 15

[IU]

Some additional observations:

After yesterday afternoon's updates, I reset app.update.interval and 
app.update.timer to 86400 and 600000, respectively.  The only difference now 
being the existence of the app.update.lastUpdateTime.background-update-timer 
preference (created automatically during the prior updates).

Today, after over 24 hours later and still no update, I changed 
app.update.timer back to 5000 and restarted the browser.  It was only after 
this that today's update was downloaded and I received the notification.

Therefore, there appears to be two problems with the present defaults: (1) The 
absence of app.update.lastUpdateTime.background-update-timer; and (2) the 
value for app.update.timer is not optimal (default = 600000 or 10 hrs).  I 
highly suspect that resolving the issues related to these two preferences man 
in all probability resolve this bug.

Comment 16

[IU]

Something else I just noticed:

Throughout this time, Firefox failed to automatically check for extensions -
even though updates were available.  This worked in the 1.0.x official builds.

Comment 17

[Asa Dotzler [:asa]]

I believe that this is all working. What are the specific bugs we're blocking on
here? I think the time for generalized and tracking bugs blocking our release is
coming to an end.

Comment 18

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I haven't really dug into this bug yet, but for sure we want to fix this:

nsUpdateService.js.in, line 842:

var interval = getPref("getIntPref", PREF_APP_UPDATE_INTERVAL, 86400000);

It *should* be:

var interval = getPref("getIntPref", PREF_APP_UPDATE_INTERVAL, 86400);

No one wants to wait 'til the last of Scheherazade's tales to get an update :)

Comment 19

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: change default interval to 1 day instead of 1000

Forgot to mention that this pref uses seconds, not milliseconds.

Comment 20

[Darin Fisher]

Comment on attachment 197924 [details] [diff] [review]
change default interval to 1 day instead of 1000

good catch, but perhaps this does not explain the problem some people are
seeing.  i wonder if it has more to do with this expression:

lastUpdateTime += Math.round(Math.random() * timerData.interval);

I think that introduces possibly too much variance on lastUpdateTime.  That may
explain why some users find that their browser doesn't get updated
automatically.	Thoughts?

Comment 21

[IU]

Also, what of this app.update.timer preference, which is defaulted to 600000 (or
10 hrs)?  Is this reasonable?

Comment 22

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I think your hunch was right, Darin. That is the problem. The value for 
timerData.interval is coming directly from app.update.interval (which is set 
at 24 hours by default). The comments mention adding a random amount of time 
with a max of 10 minutes, which is the default value for the app.update.timer 
pref. So instead of 24hrs+(% of 10min), we're getting 24hrs+(% of 24hrs). We 
need to switch the value passed to registerTimer. Working on a patch.

Comment 23

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: Fixes the timer intervals

Fixes the above-mentioned.

Comment 24

[Darin Fisher]

Comment on attachment 197945 [details] [diff] [review]
Fixes the timer intervals

nice!  it might be nice to pull the getPref call outside of the Math.round call
so that the line does not exceed 80 chars.  otherwise, this looks good.  beng
also looked it over and agreed that this is what was intended.

r=darin

Comment 25

[Darin Fisher]

Attachment: v1.1 patch

Here's the actual version of the patch that I checked into the trunk.

Comment 26

[Darin Fisher]

fixed-on-trunk

Comment 27

[Darin Fisher]

fixed1.8

Comment 28

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I see this on 1.8, but I don't see it on the trunk...

Comment 29

[Darin Fisher]

fixed-on-trunk for real.  thanks ben for noticing my snafu!

Comment 30

[Matt]

Uh, I'm still having this bug...
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051002 Firefox/1.6a1
ID:2005100204

Kinda hoped it was fixed when you said it was, but I still don't get an update.

Comment 31

[Ben Turner (not reading bugmail, use the needinfo flag!)]

try comment #12's steps...

anyone else seeing this on linux?

Comment 32

[IU]

(In reply to comment #30)
> Uh, I'm still having this bug...
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051002 Firefox/1.6a1
> ID:2005100204
> 
> Kinda hoped it was fixed when you said it was, but I still don't get an update.

I am still suspicious that the *REAL* problem is tied to the initial absense of
a value for the app.update.lastUpdateTime.background-update-timer preference,
per my theory in Comment #11, but I haven't yet retested.  Now that a recent
problem with the update server has been resolved, I will wait for the next
successful update then reset my app.update.timer value to 600000 and also reset
app.update.lastUpdateTime.background-update-timer to no value (hopefully this
means it will no longer be listed in about:config, as it initially is not) and
retest will all other update preference at their defaults.

I highly suspect that once app.update.lastUpdateTime.background-update-timer has
been reset, Auto Update will again fail - until aggressive timings are once
again applied so that app.update.lastUpdateTime.background-update-timer can be
assigned an initial value, during that browsing session.  

Comment 33

[Trevan]

reply to comment #31)
> try comment #12's steps...
> 
> anyone else seeing this on linux?

Automatic update hasn't worked for me either.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051002 Firefox/1.4.1(In 

Comment 34

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Ok, so I definitely missed something and that's probably what you folks are 
running into. It looks like if the app.update.lastUpdateTime.background-update-
timer pref isn't set then the timer has no way of knowing when the last update 
attempt was made. So every time firefox starts it sets a brand new timer for 
24 hours. Only after those 24 hours are up does this pref get written. That 
means that auto update will NEVER run if you have no pref and you don't let 
firefox run for 24 hours. I have a patch ready that should fix this, but I 
don't have a build to test it on. I could use some help with that. Patch to 
follow. Reopening.

Comment 35

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch to write lastUpdateTime pref if it doesn't exist

see comment 34

Comment 36

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 198485 [details] [diff] [review]
patch to write lastUpdateTime pref if it doesn't exist

>   registerTimer: function(id, callback, interval) {
>     var preference = PREF_APP_UPDATE_LASTUPDATETIME_FMT.replace(/%ID%/, id);
>-    var lastUpdateTime = getPref("getIntPref", preference, 
>-                                 Math.round(Date.now() / 1000));
>+    var lastUpdateTime = null;
>+    try {
>+      lastUpdateTime = gPref.getIntPref(preference);
>+    }
>+    catch (e) {
>+      if (PREF_APP_UPDATE_TIMER_ID_SUFFIX == id) {
>+        var now = Math.round(Date.now() / 1000);
>+        gPref.setIntPref(preference, now);
>+        lastUpdateTime = now;
>+      }
>+    }
>     this._timers[id] = { callback       : callback, 
>                          interval       : interval,
>                          lastUpdateTime : lastUpdateTime }; 
>   },

This change means lastUpdateTime can now be null (if
PREF_APP_UPDATE_TIMER_ID_SUFFIX != id and the pref doesn't exist). Is that
intended?

Comment 37

[:Gavin Sharp [email: [e-mail]]]

Perhaps the following would be clearer?

var now = Math.round(Date.now() / 1000);

var lastUpdateTime = getPref("getIntPref", preference);

if (!lastUpdateTime) {
  if (PREF_APP_UPDATE_TIMER_ID_SUFFIX == id)
    gPref.setIntPref(preference, now);
  
  lastUpdateTime = now;
}

Comment 38

[IU]

(In reply to comment #34)
> I have a patch ready that should fix this, but I 
> don't have a build to test it on. I could use some help with that.

I don't know how to make custom builds.  I don't even know how to build (too
lazy). :-(  However there are people on the MozillaZine Firfox Builds Forum who
could help.  I will post a notice.

Comment 39

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch to write lastUpdateTime pref if it doesn't exist v2

Well, the issue is that the extension update system also uses this function
check for the timer id "addon-background-update-timer". Looking over that stuff
I initially decided that I didn't know enough about what was going on to make a
change that might affect the extension manager. That was why I added the
'if(PREF_APP_UPDATE_TIMER_ID_SUFFIX == id)' statement and introduced that
potential new bug (thanks Gavin!). However, after looking over it a little
more, it seems that the extension update checks are in the same shape that app
update was in before this bug. So I'm thinking that we should just get rid of
the id check altogether. We'll have to look into the extesion update sometime
soon. Attached the final patch that I *think* should finally resolve this bug.

Comment 40

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch to write lastUpdateTime pref if it doesn't exist v3

Same as v2, but using prefHasUserValue instead of the try/catch mess.

Comment 41

[Darin Fisher]

Comment on attachment 198508 [details] [diff] [review]
patch to write lastUpdateTime pref if it doesn't exist v3

r=darin

Comment 42

[IU]

Something to also note (and I've harped about this, but it is getting ignored)
is that auto checking for extension updates does not work in these Branch builds.

Comment 43

[Darin Fisher]

(In reply to comment #42)
> Something to also note (and I've harped about this, but it is getting ignored)
> is that auto checking for extension updates does not work in these Branch builds.

IU: Can you elaborate on what you mean, or point me to where you have mentioned
this in more detail previously?  I'm not sure I understand the problem you're
describing.  Thanks.

Comment 44

[IU]

(In reply to comment #43)
> IU: Can you elaborate on what you mean, or point me to where you have mentioned
> this in more detail previously?  I'm not sure I understand the problem you're
> describing.  Thanks.

I first mentioned it here in Comment #16.  Okay, I guess Mozillazine must have
been the other place I mentioned it (so I guess I wasn't quite harping on here :-)

Anyhow, if you recall the behavior of 1.0.x, that you receive a notification
when an extension update is available, you should notice the complete absence of
any notification whatsover that an extension update is available using the
Branch (not even a silent update of an extension, nor a notification when auto
update is working, nor a notification when manually running Software Update). 
Never ever ever since I've tested the Branch - even though I can always manually
check and Firefox finds updates - even after several days of not checking.

Comment 45

[Darin Fisher]

v3 patch fixed-on-trunk

Comment 46

[Scott MacGregor]

I checked this into the branch.

Comment 47

[Darin Fisher]

Thanks Scott!

Comment 48

[IU]

Almost there, but not quite.

The previous entry in my about:config was:
app.update.lastUpdateTime.addon-background-update-timer

Now, with the patch, I also get an entry:
app.update.lastUpdateTime.background-update-timer

Since the previous entry was created by Firefox, prior to the patch, once of
these entries is going to get ignored; but which one?

Comment 49

[IU]

Others have confirmed the double-entry bug (Comment #48).  See here:
http://forums.mozillazine.org/viewtopic.php?p=1789941#1789941 and here:
http://forums.mozillazine.org/viewtopic.php?p=1789953#1789953

Comment 50

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to comment #48)
> The previous entry in my about:config was:
> app.update.lastUpdateTime.addon-background-update-timer
> Now, with the patch, I also get an entry:
> app.update.lastUpdateTime.background-update-timer

In comment 32 you were talking about app.update.lastUpdateTime.background-
update-timer... did you get those two confused?

> once of these entries is going to get ignored; but which one?

These are two separate timers. One controls extension update, the other 
controls app update. I believe that the extension update code is going to be 
broken for a little while longer, and we'll have to have a new bug for that one 
(Want to file it?). This bug is all about app update. So with this patch does 
everything work as expected with app update?

(In reply to comment #49)
> Others have confirmed the double-entry bug

This is not a bug. Resolving fixed.

Comment 51

[IU]

(In reply to comment #50)
> In comment 32 you were talking about app.update.lastUpdateTime.background-
> update-timer... did you get those two confused?

Arr me mates. :-)

Silly me.  I did not know there were two separate such (legitimate) prefs for
two separate components.  I guess that patch fixed them both.  Forgive my
mindless... err... umm... ravings. :drools uncontrollably:

Comment 52

[Dave Townsend [:mossop]]

*** Bug 311656 has been marked as a duplicate of this bug. ***