316328 - Update History window shows incorrect date and time after automatic update was installed

Status: RESOLVED DUPLICATE of bug 576939

(Toolkit :: Application Update, defect)

Description

[Peter McClymont]

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

A dialog popped up saying that Mozilla was installing an automatic update (turned out to be a security update). I went to the Update History window and it states that the update was installed on 'Thursday, 1st January 1970, 1:00:00 p.m.'

Reproducible: Always

Steps to Reproduce:
1. Automatically receive update 'Firefox 1.5 (2005110712)'
2. Go to 'tools' menu -> 'Options' -> click 'Show Update History' button
3. Look at item that says 'Security Update' in listbox to see issue

Actual Results:  
Date was wrong

Expected Results:  
Date should be today

I will send through a screen shot of the results by e-mail if requested. Not convinced this will help much though.

Comment 1

[Ria Klaassen (not reading all bugmail)]

WFM. Your system battery is OK?

Comment 2

[Peter McClymont]

(In reply to comment #1)
> WFM. Your system battery is OK?
> 

The date and time on my machine was correctly set when the update occured. CMOS battery is fine, no issues with that.

Comment 3

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

Is this still happening?

Comment 4

[Peter McClymont]

(In reply to comment #3)
> Is this still happening?
> 

Not sure. The funny date dissapeared the next time it did an update, but the funny thing about that is in the list it only says there has been 1 update, where there has actually been 2 updates (1 with the funny date, and another once since then).

Haven't received an update since then, so have not been able to check whether there is still something funny going on there.

Comment 5

[Peter McClymont]

OK got it now, the initial update that occured was 'Firefox 1.5 (2005110712)' which showed the dodgy date. If I look at the update list this one is not there any more.

There is one there now with the correct date called 'Firefox 1.5 (2005111116)'. This update has occured since that first update.

So my question is why is the initial update not in the list any more? Still seems like there is an issue there.

Comment 6

[Josh Birnbaum]

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

Comment 7

[Art Masson]

I have a similiar problem with Thunderbird 1.5.0.2 update -- which is showing in my update history as Dec 31, 1969.  My PC battery and time is OK.  Please see
http://forums.mozillazine.org/viewtopic.php?t=377278
Art Masson

Comment 8

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 9

[Daniel de Wildt]

I also saw this WHILE I'm downloading an update for firefox 2:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20060919 BonEcho/2.0 

Comment 10

[Daniel de Wildt]

Attachment: Screenshot showing the bug

The screenshot is taken after I installed an old nighlty and updating again.

I guess that the update entry is initialized but not filled with useful data at that moment => The status is also empty and not showing 'downloading update' or something like.

Comment 11

[Daniel de Wildt]

Maybe the update 'installDate' and 'statusText' of the '_update' must be set downloadUpdate (see nsUpdateService.js.in)?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in&rev=1.77.2.42&mark=2242,2285,2416-2417#2235

The first two lines mark the function and the second two lines are an example how it's done in 'onStopRequest'.

Comment 12

[Mike Connor [:mconnor]]

at this time this seems mostly fixed, and is not a regression from 1.5, not going to block on this.

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 16

[Onno Ekker [:nONoNonO UTC+1]]

Attachment: Update History showing RC1 installed with init date

I hit this bug too after (auto) downloading Firefox 3.0 RC1, but before restarting Firefox and/or installing the update. In this case the Update History incorrectly shows RC1 as installed, with init time January 1, 1970, 1:00:00

Comment 17

[Robert Strong (they/them - no direct email)]

Onno, could you attach your updates.xml file to this bug? It should either be in your application directory in the updates subdirectory (usually c:\Program Files\Mozilla Firefox\) or in the %LOCALAPPDATA%\Mozilla\Firefox\Mozilla Firefox\updates (Mozilla Firefox in the path would be different if you installed into a different directory than the default).

Comment 19

[Jason Morris]

I was able to duplicate this while downloading 3.0.10 today on my managers computer. I have the screen shot and log file if you need them.

Comment 20

[Robert Strong (they/them - no direct email)]

Is this reproducible with 3.5.x? We no longer store the active update in history which is the only known cause of this bug.

Comment 22

[brendaludick]

Noticed in my firefox updates that my 3.5.2 version was updated December 31, 1969 at 6:00 p.m..  What's up with that?  My 3.5.1 version update was July 20, 2009.  I'm pretty sure I found these update dates when I went through tools and then options...but now when I try it nothing happens.  My computer went haywire yesterday and looked like it loaded a virus (since it said worm..trogan...loading all my files...firefox online...).  I tried to shut it down, but it wouldn't until it finished.  My Norton 360 scan didn't show any virus.  I only saw these updates when I went through checking on what happened with my computer.  I don't know if this has anything to do with this or not, but it is kind of weird.  Anyone know anything about this problem?

Comment 26

[Michael]

How can this be marked as "resolved"???  I see nothing about a "fix" or anything that justifies a "resolved" problem.  (I posted bug #517911 and I haven't received a "fix" through e-mail nor have I seen on this site a "fix" posted.)

Comment 28

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #20)
> Is this reproducible with 3.5.x? We no longer store the active update in
> history which is the only known cause of this bug.

Bug 523066 is a 3.5.2 -> 3.5.3 update.

Comment 29

[Michael]

Can anyone tell me how a bug "discovered" in 2005 is the same bug that was "discovered" in 2009?  Does not compute.

Comment 32

[krinya007]

On 3.5.5 non-beta still bugged, but not only 1 update shows as installed on 1970. Jan. 1, 1:00AM -- all of it since 3.5.1

Comment 34

[Masahiro YAMADA]

Attachment: patch rev.1.0 for Trunk

Comment 35

[Robert Strong (they/them - no direct email)]

Comment on attachment 419000 [details] [diff] [review]
patch rev.1.0 for Trunk

Do you know what the root cause is for this glitch?

Comment 36

[Masahiro YAMADA]

(In reply to comment #35)
> (From update of attachment 419000 [details] [diff] [review])
> Do you know what the root cause is for this glitch?

Default value of installDate is 0.
(see http://hg.mozilla.org/mozilla-central/annotate/9fffe45aca7d/toolkit/mozapps/update/src/nsUpdateService.js.in#l823)

Comment 37

[Masahiro YAMADA]

(In reply to comment #36)
> Default value of installDate is 0.
> (see
> http://hg.mozilla.org/mozilla-central/annotate/9fffe45aca7d/toolkit/mozapps/update/src/nsUpdateService.js.in#l823)

And, installDate is never updated until onStopRequest() is called.

http://hg.mozilla.org/mozilla-central/annotate/9fffe45aca7d/toolkit/mozapps/update/src/nsUpdateService.js.in#l2474

Comment 38

[Robert Strong (they/them - no direct email)]

Let's go with setting a reasonable default using (new Date()).getTime(); to prevent this from happening. The date should probably also be updated after the update has been applied when the updates.xml file is updated after an update so it is closer to the actual time the update was applied. I think a string such as "unknown" should be displayed as well for the start of unix time case instead of not displaying anything.

Comment 39

[Jay]

Last three automatic updates of 3.5.4, 3.5.5 and 3.5.6 have done the same for my Win XP install (showing date Thursday, 1 January 1970, 09:30:00 AM).

Latest version is : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6

Comment 40

[Robert Strong (they/them - no direct email)]

Additional "me too's" aren't necessary at this point.

Comment 41

[Dave Townsend [:mossop]]

Comment on attachment 419000 [details] [diff] [review]
patch rev.1.0 for Trunk

Sounds like Rob has better input here, passing over the review

Comment 42

[Robert Strong (they/them - no direct email)]

Comment on attachment 419000 [details] [diff] [review]
patch rev.1.0 for Trunk

minusing per comment #38

Comment 45

[Robert Strong (they/them - no direct email)]

This is fixed on trunk by bug 530872 but it doesn't try to fix the display of old entries in any way. Since the best we can do is display "unknown" for the date for the updates previous to the fix I think this is as fixed as it is going to get. There is a good chance that bug 530872 will be backported to 3.6 and possibly 3.5 as well but updates prior to the fix will still display the incorrect date.

I'm going to leave this open until after bug 530872 is backported and the version it is backported to released.

Comment 48

[Robert Strong (they/them - no direct email)]

With the landing of bug 576939 for Firefox 3.6.9 this should be fixed for updates after 3.6.9 has been applied

Comment 49

[Robert Strong (they/them - no direct email)]

Per comment #48 this should be fixed for future updates after 3.6.9 so resolving duplicate of bug 576939