User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20060909 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20060909 Firefox/220.127.116.11 Previous version was 18.104.22.168. User Agent string shows it is successfully updated to 22.214.171.124 already. Sometimes after Firefox starts I get window that new version (126.96.36.199) is available. My Firefox already "updated" to 188.8.131.52 three times :) . May Reproducible: Sometimes Steps to Reproduce: 1. Open Firefox Actual Results: Update dialog shows possibility to update to 184.108.40.206. "Update" is performed successfully after confirmation. Expected Results: Firefox should just open, as it is already 220.127.116.11 May it be a duplicate of Bug#314684?
It's possible for everything except firefox.exe to get updated, usually when another application is holding a lock on the executable, or firefox does not exit completely. Then the UI will say 18.104.22.168 but the exe is 22.214.171.124, and the latter is used for the version when requesting updates. Please look at the properties of firefox.exe, in the Version tab, at the fields in the Item List. You should have "126.96.36.199: 2006090918" for "File Version". You may also get some information from C:\Program Files\Mozilla Firefox\updates\last-update.log, and updates\0\update.log (if it exists). Attaching those to this bug may be useful.
Version: unspecified → 1.5.0.x Branch
This might be the same as I am seeing. Was 188.8.131.52, upgraded to 184.108.40.206 and the following day the "about" page said it was 220.127.116.11! And it did an upgrade again. After this happening twice, I uninstalled firefox (but kept my profile) and installed from a fresh download of en-US. I disabled auto updates completely and when I came in the next day, there was 18.104.22.168 back again. The version of Firefox.exe confirms this. I wonder if there is some system restore activity going on. I have archived copies of the "program files" tree and will check for any overwriting.
System Restore can cause problems, see bug 351216.
I had not actually used system restore - I was confusing myself there - thinking about some automated process that might run while I wasn't looking. A bit more info. Firefox was running overnight, and the replacement to 22.214.171.124 occurred at 05:33. There is a windows prefetch entry for "Firefox Setup 126.96.36.199.exe" at that time, as well as one for 188.8.131.52 when I later came in and performed the manual update. Also in D:/temp/sys/ff_temp/... (from memory) were dlls for firefox 184.108.40.206. Dates/times were also tuesday at 05:33 The ff 220.127.116.11 versions of these files were under D:/tmp/..., which is actually a different folder on my system. Now, D:/temp/sys is the TEMP enviroment variable for the system, not for me. So it looks exactly as if the 18.104.22.168 setup program was run behind my back. There was no record of 22.214.171.124 in the "update history" box (tools->options->advanced) - only the 126.96.36.199. . There is no copy of the 188.8.131.52 setup executable that I can find anywhere on my system or attached network drives. Last night FF was not running and there was no change. Even more curiously, I borrowed a laptop two days ago - one that I had never previously used - and noticed that even though FF was set for fully auto-updates, it only had 184.108.40.206. After getting admin rights, I upgraded to 220.127.116.11, shut down overnight, and the next day is was on 18.104.22.168 again. The "show update" history said 22.214.171.124 was updated at 13:36, but the firefox.exe is version 126.96.36.199 and create time is Oct 15-2005, modified time is Tuesday at 14:35, one hour after I upgraded to 188.8.131.52. I just updated it to 184.108.40.206 again, and the previous history has been wiped out. This may be irrelevant, but I notice registry entries on both machines to HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\ShellNoRoam\MUICache referring to "D:\\TEMP\\sys\\Firefox setup 220.127.116.11.exe"="Firefox" (and the appropriate temp dir on the other machine) There is a duplicate entry under the S-1-5-18 sid (the "local system" user)
I think I may have found the cause of my problems and it might have wider implications. It seems our corporate IT support implemented automatic upgrades to Firefox, but after 18.104.22.168 they have forgotten about it. When you do "properties-> version" on firefox.exe there are two different file versions. One is on the main page itself, and a different value is visible when you select "file version" under the "item name" list. item : 22.214.171.124: 2006030804 shows 1.8.20060.30804 on the top line but item : 126.96.36.199: 2006090918 shows 1.8.20060.25382 on the top line So if scripts use the top "file version" then 188.8.131.52 looks newer, and this old script that has been forgotten about suddenly springs to life.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20060920 BonEcho/2.0 I'm on Win98 (german) and use zipped builds, looking at the properties of 184.108.40.206 gives me: file version: 220.127.116.11: 2006082915 product version: 18.104.22.168
Created attachment 239488 [details] illustration of version mismatch oops, sorry.. The file version under "item name" should read 1.8... in both cases. But my point is that there are two different "file versions" and they compare inconsistently. I have attached an image illustrating what I am referring to. Ignoring the missing ".0.7", the trailing 5 digit number on the top is lower for 22.214.171.124 than for 126.96.36.199. For 188.8.131.52, the top trailing fragment was created by the date
cameron, do you still have this update problem also from Firefox 184.108.40.206 to Firefox 220.127.116.11 ?
Whiteboard: CLOSEME - 07/02
This is likely a dupe of the other issues we've had related to receiving the same update twice. Closing it as INCOMPLETE due to lack of information. Cameron, if you can still reproduce using Firefox 2.0.0.x (since 1.5.0.x is no longer supported), please comment here.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.