689059 - Firefox and Thunderbird do not update automatically even if set to do so

Status: RESOLVED DUPLICATE of bug 624813

(Toolkit :: Application Update, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a2) Gecko/20110907 Firefox/8.0a2 ID:20110907042004

Today I have seen that I was still running on a Firefox Aurora build from Sep, 7th. Since then Firefox has never updated itself or even proposed me an update, even with the automatic update pref enabled in the preferences. To circumvent that I always have to check for updates by opening the about dialog.

I have seen the same for Thunderbird since a while, which behaves the same.

Why don't get we application updates anymore even if the application is running 24/7? Especially non-advertised ones. Could that be a reason why a lot of people are stuck with older versions of Firefox?

Rob, if you need any debugging data please let me know and I can try to get those.

Comment 1

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

Anything changed lately on your system or your settings?

btw: I just updated to the 9/25 build with no problem.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

No, I haven't changed anything since ages. It probably hasn't started lately because I normally run the update manually by opening the about dialog. But in the last two weeks due to the All Hands and the QA work week I never did that. So it wasn't that obvious to me before today.

Comment 3

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

Could you try running with a new profile for a day to see if you get notified?

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sure, I will also downgrade my Aurora build to the one from yesterday to make the event happening earlier.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

With the fresh profile the updater pinged the AUS server correctly and offered the update. I will now make a copy of my daily profile and let it run in parallel. It will probably take some days until I can report back.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Today I have cleared everything possible inside the clear recent history dialog on that profile. Now an update check is performed. Will further investigate which section could affect this issue.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Rob, something seems to be totally wrong with the last update timestamps in my profile. Why do we have those strange numbers in a couple of cases only? Resetting the 'background-update-timer' preference and restarting the browser solved this problem. Personally I have never tweaked those timestamps. So I really don't know why such a value has been set.

> user_pref("app.update.lastUpdateTime.addon-background-update-timer", 1897287132);
> user_pref("app.update.lastUpdateTime.background-update-timer", 1897287132);
> user_pref("app.update.lastUpdateTime.blocklist-background-update-timer", 1897287132);
> user_pref("app.update.lastUpdateTime.microsummary-generator-update-timer", 1897287134);
> user_pref("app.update.lastUpdateTime.personas-data-refresh-timer", 1259060143);
> user_pref("app.update.lastUpdateTime.personas-favorites-refresh-timer", 1259060155);
> user_pref("app.update.lastUpdateTime.personas-persona-refresh-timer", 1259060873);
> user_pref("app.update.lastUpdateTime.places-maintenance-timer", 1897287134);
> user_pref("app.update.lastUpdateTime.restart-nag-timer", 1213487186);
> user_pref("app.update.lastUpdateTime.search-engine-update-timer", 1897287134);

Shouldn't we better test for invalid timestamps? In this case for a timestamp which located in the future, which should never happen.

Comment 8

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

That could be bug 624813

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sounds like. I can remember that I have had to set the time to a future date to check for an expired SSL cert. It's very likely that the update timer has updated the preferences during that timespan. Marking as dupe, because I have no other idea which could have been caused this issue.