User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729) I had version 3.0.10 installed and running, when I got the popup that a "new" version has been published and automatically installed. It said that the new version 3.0.4 is available - although I had 3.0.10 installed. After a restart of firefox, the page http://de.www.mozilla.com/de/firefox/3.0.4/whatsnew/ was shown, which says that I have "the most recent version" installed. When I first tried the built-in check-for-update feature, I got an error message (something about an XML file). Now, 30 minutes later, it says that the new version 3.0.10 is available and that an urgent update is recommended. So there are mainly two problems: first, why did it downgrade? And second, the pages which are shown after an update, obviously hard coded pages which are static, should not say "you have the latest version installed" if there are newer versions available already. These pages should either check the version of the current browser or simply redirect if they are not about the most recent version anymore. Reproducible: Didn't try

Cc'ng a couple people who may have insight. What would cause his update channel to lie to him? Leaving sec-sensitive for now. This is unlikely to be an exploitable bug, I think, but if it were, downgrading users is bad news.

We should check the snippets for 3.0.10 de and see what might be happening. Christian: Can you find out what update channel you're on? "To check which channel you are on, look in about:config at app.update.channel."[1] (about:config is a URL you can enter into your browser. Don't change other settings though.) [1] http://kb.mozillazine.org/Software_Update#Update_channels_-_Advanced

This smells alot like bug 313057, fixed in 3.5 but not 3.0.

Bug 485624 makes it so we check downloads in progress on startup and if it is for a previous version the download is canceled. Bug 313057 checks the update's version prior to applying a previously downloaded update and if it is for an older version it doesn't apply it. So, this bug is fixed for 3.5 in separate ways by these two bugs.

mconnor rejected bug 313057 for inclusion in FF 3.0.6, but given how alarming a downgrade is to users should we reconsider? Not to mention that it leaves users vulnerable to published security problems until they can download the new version. After the downgrade their copy won't check for updates for at least a day (unless they notice and do it manually), and if they're light internet users it could take a while to trickle down in the background, and then won't apply until they restart after that -- that could easily be two or more days running the old version. On the positive side we have not ever seen any Firefox 3.x security flaws used in an attack, the few attacks we've seen have always been for much older versions. And Firefox 3.5 is almost released...

The support team might want to know about this affecting users, if they don't already.

btw: if drivers would like branch patches for Bug 485624 and / or Bug 313057 I would be glad to do so.

I think it's baked long enough that we can take bug 313057 now, but I'd want to know how this happened...

Bug 313057 handles the case where an update has been "staged" (e.g. it has been downloaded and is ready to be applied). The typical case where this can happen is when a user starts an update download, the app is upgraded by another user, the user that started the download runs Firefox again. The installer tries to prevent this by removing the directory with the update in it but this of course doesn't work with the two user scenario as described. btw: I wrote the patch for Bug 485624 (and Bug 313057 for that matter) so it could easily be backported. Also, Bug 313057 does have a unit test if that makes you any more comfortable with accepting it.

The update channel is "release" The computer on which this problem occurred is used by two users.

Christian, does one of the users log in or use Firefox very infrequently (not the primary browser or computer)? I can't say I've seen this a lot -- most of the update confusion around 3.0.10 revolved around thinking it was the same as 3.0.1.

btw: You can see the same / similar symptoms via the dupes on both Bug 485624 and Bug 313057. I highly suspect the confusion between 3.0.10 and 3.0.1 is the same issue

Cww: yes, one users logs in very infrequently, maybe once in a month (and even then I don't have to use firefox with that user often).

BTW, I had definitely 3.0.10 installed when it downgraded to 3.0.4.

(In reply to comment #9) > Bug 313057 handles the case where an update has been "staged" (e.g. it has been > downloaded and is ready to be applied). The typical case where this can happen > is when a user starts an update download, the app is upgraded by another user, > the user that started the download runs Firefox again. The installer tries to > prevent this by removing the directory with the update in it but this of course > doesn't work with the two user scenario as described. One other thing I forgot to mention that exacerbates this is that the silent update throttles the download which can cause a full download to take several hours. > btw: I wrote the patch for Bug 485624 (and Bug 313057 for that matter) so it > could easily be backported. Also, Bug 313057 does have a unit test if that > makes you any more comfortable with accepting it.

(In reply to comment #13) > Cww: yes, one users logs in very infrequently, maybe once in a month (and even > then I don't have to use firefox with that user often). I think that adequately explains this bug then, that's definitely the scenario covered by bugs 313057 and 485624.