942 bytes, text/xml
the snippet saved locally from my hybrid 2.0-184.108.40.206 firefox as a result of upgrading, switching users, and not quitting
978 bytes, application/xml
1.57 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 I have installed FireFox 2. Now the automatic updater has downloaded version 1.5.8. Shouldn't the updater check to see which version has been previously before downloading an older version? Reproducible: Always Steps to Reproduce: 1. It happened automatically. 2. I received an alert box that indicated that FireFox downloaded FireFox 1.5.8. Do I want to install now or later? Actual Results: I have not installed it yet. I click on the close icon on the top right side of the alert box, to avoid installing an older version.
Summary: The automatic updater is updating an older version → Firefox 2 auto update offers update for Firefox 220.127.116.11
firstname.lastname@example.org, what is the value of your app.update.channel pref? I hate to point the finger at the server side, without knowing any details, but could we be pushing 18.104.22.168 on a 2.0 channel (accidentally?) do we have a way to see all snippets for all 2.0 channels?
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 on Windows XP x64 with channels betatest and release. "No Updates were found." Also no similiar reports on mozilla feedback.
additionally, could you set the app.update.log.Checker pref (using about config), restart, and see what appears in your JS error console?
I also could not reproduce this using the "release" channel. I was testing on XP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0. I looked through Hendrix and do not currently see any other reports of this, I am next going to MozillaZine forums. Will report back.
After some research on other community sources: There are other reports about Auto-Update offers from 2.0 -> 22.214.171.124. It seems that this happens only with old profiles that exists during 150x. See also http://forums.mozillazine.org/viewtopic.php?t=485744
Confirming -- I've seen enough reports of this on IRC today. One guy was on Mac, had it happen to two different computers. A WinXP guy had it happen twice: got downgraded, reinstalled 2.0, got downgraded again. He had no extensions other than Chatzilla.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
I will try some testing on Mac. I have some good profiles that have been back and forth between 1.5.0.x and 2.0.
OS: All → Windows XP
Hardware: All → PC
Seems important to clean this up ASAP. Nominating for the next releases in case it turns out to be a client issue. I don't believe update uses any version info from the profile, but is it possible that a 2.0 install over a 126.96.36.199 would leave something behind? No, but that can't happen in the Mac case. But morgamic/sspitzer/preed have checked out the aus files, and they are all correct. So the client can't be asking for the wrong thing, and the server can't be serving the wrong thing... and clearly if it were either this would be happening to a whole heck of a lot more people. Could the caching thing between the users and aus be getting messed up?
OS: Windows XP → All
Hardware: PC → All
(In reply to comment #8) > I don't believe update uses any version info from the profile, but is it > possible that a 2.0 install over a 188.8.131.52 would leave something behind? No, > but that can't happen in the Mac case. I think we should explore this more. > Could the caching thing between the users and aus be getting messed up? > The Netscaler would be failing at what something pretty basic if that were the case -- it caches by URI, so this is pretty unlikely -- but I'll defer to Justin on that one.
This could be more fallout from bug 357922, at least on Windows. The problem with that bug is that it leaves all the executables unchanged from 1.5.0.x, in particular firefox.exe which gives the crucial BuildID used for querying AUS. Some of the strings at Help > About Mozilla Firefox come from chrome, so that UI can still say Firefox 2 in this situation, but the full useragent is thought to be reliable. However, given the severity of the symptoms reported in bug 357922 it seems unlikely that people wouldn't notice something was wrong until the "please restart for 184.108.40.206" dialog. It also doesn't explain the reports on the Mac.
in #builds, TomCat (Carsten Book) writes: "there are other reports about an update offer from 2.0 -> 1508"
(In reply to comment #11) > in #builds, TomCat (Carsten Book) writes: "there are other reports about an > update offer from 2.0 -> 1508" Yep, was releated to comment #5 :) We have 2 other reports on the German Community Forum, so this Problem also affect locales. -> People did not make a clean install of Firefox 2 (uninstalled 1507 - installed 2.0) , they did "manually upgraded" from 1507 to 2.0, so i think also this could be a Problem like Bug 357922 and comment #10. -> Both were (in reference to their Forums Sig.) Windows User (XP/Windows 2000) -> The Auto-Update notice occur (for the first time) on 2006-11-08 -> One user with this 2.0 -> 220.127.116.11 issue dissmissed the auto-update offer and checked later manually via Help -> check for Updates .... Result: no updates found I will do some Tests on XPx64/Windows 2000/XP Sp2 and i hope i could reproduce this on some way.
Here is the Summary from one of the german Users, getting this 1508 Update offer: 1. OS: Windows XP 2. Extensions used: Adblock Plus Ain One Sidebar Console² DOM Inspector Google PageRank Status[de]HTML- Validator IE View Inspect This Long Titles Measure IT OperaView PearlCrescent Page Saver Basic Inhide Passwords Web Developer 3. Channel: release After he posted this information at the Forum, he got that update offer again.. will try to reproduce with this information...
Created attachment 245199 [details] Updates.xml file from this user running Firefox 2 and get auto-update offers for 18.104.22.168
(In reply to comment #14) > Created an attachment (id=245199)  > Updates.xml file from this user running Firefox 2 and get auto-update offers > for 22.214.171.124 Unfortunately that looks like a normal 126.96.36.199 -> 188.8.131.52 partial update. Could you please ask the user to 1, Copy the Useragent from the bottom of Help > About Mozilla Firefox and report it back 2, Install the LiveHTTPHeaders extension from http://livehttpheaders.mozdev.org & restart Firefox, go Tools > LiveHTTPHeaders, Help > Check for Updates, copy the request URL from the top Headers tab and report it back
I don't know what to make of carsten's comment #14 (since the update xml snippet was for 184.108.40.206 -> 220.127.116.11), but let me add some data into the mix that might be helpful. when someone runs into this bug, it would be useful to see the snippet, or even better, to have set app.update.log.Checker and then look in the JS error console for an item like: checkForUpdates: sending request to https://aus2.mozilla.org/update/2/Firefox/2.0/2006101023/WINNT_x86-msvc/en-US/release/Windows_NT%205.1/update.xml (From carsten's attached snippet, he has serviceURL="https://aus2.mozilla.org/update/1/Firefox/18.104.22.168/2006072814/WINNT_x86-msvc/de/release/update.xml") note the url version "1" vs "2" (after "update/"). For the MOZILLA_1_8_BRANCH, it was changed to "2" for bug #341190. For the MOZILLA_1_8_0_BRANCH, it is is till "2" compare: http://lxr.mozilla.org/mozilla1.8.0/source/browser/app/profile/firefox.js#97 and http://lxr.mozilla.org/mozilla1.8/source/browser/app/profile/firefox.js#105 I'm eager (like nick and preed) to see when someone hits this bug while running Fx 2, what that update url is. fwiw, I have tried on windows xp to install 22.214.171.124 and install Fx 2.0 on top of it (while fx 1.5.07 was running, and while it was not running) and I have not run into this bug yet.
I set up a broken build in the style of bug 357922, using 126.96.36.199 and fast-user switching. I get the "missing" (really hidden) bookmarks, and the Useragent at Help > About Mozilla Firefox is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060909 Firefox/2.0 and at about: is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/undefined Firefox/2.0 Unfortunately Help > Check for Updates is disabled, and LiveHTTPHeaders doesn't catch any requests (even though I've set the update interval to 60s and app.update.lastUpdateTime.background-update-timer is incrementing correctly). However, it also doesn't prompt me to install 220.127.116.11.
From the something-I-tried-but-didnt-help-figure-out-a-test-case dept: I installed 18.104.22.168, got the update for 22.214.171.124 and downloaded it, but did not restart and apply it. (so the update was on disk, waiting for my next restart). then, I used another browser to get Fx 2.0, and install on top of 126.96.36.199, and then started up 2.0.
warning: this is going to sound like I'm blaming the user, but honest, I'm not! preed and I sat down and tried this: install 188.8.131.52 in a custom location, say "c:\1507", and then get Fx 2 and attempt to install on top (which could easily be c:\1507\Mozilla Firefox", depending on how use used the installer) if someone did a custom install originally, the easily think that they were installing Fx 2.0 on top of 184.108.40.206, but really they weren't, leaving them with both Fx 220.127.116.11 and 2.0. I can dream up a scenario where they think they are running Fx 2, but they really start up 18.104.22.168 (from an old shortcut), and then get prompted for the 22.214.171.124 upgrade.
I'm starting to think that nick thomas is on to something with his comment #10, where he points us back to bug #357922 jesse writes in bug #357922 comment 29: 'it seems like a lot of people who are seeing the "tabs not working" problems have user agents like "rv:126.96.36.199 ... Gecko/20060909 Firefox/2.0".' I jumped through the hoops to get into that state (install 188.8.131.52 as admin user X, leave 184.108.40.206 up and running, switch to admin user Y, install Fx 2.0 on top of 220.127.116.11, quit Fx 2.0, switch back to admin user X, start Fx back up, and you are in the dreaded 'rv:18.104.22.168 ... Gecko/20060909 Firefox/2.0' state) from there, software update menu item is disabled, but I was able to force it and get a 22.214.171.124 update! from the update snippet: serviceURL="https://aus2.mozilla.org/update/2/Firefox/126.96.36.199/2006090918/WINNT_x86-msvc/en-US/release/null/update.xml" note, the update version is "2" but the fx version is 188.8.131.52, proof that something is bad. I'll attach the full snippet.
Created attachment 245300 [details] the snippet saved locally from my hybrid 2.0-184.108.40.206 firefox as a result of upgrading, switching users, and not quitting
(In reply to comment #19) > warning: this is going to sound like I'm blaming the user, but honest, I'm > not! > > preed and I sat down and tried this: install 220.127.116.11 in a custom location, say > "c:\1507", and then get Fx 2 and attempt to install on top (which could easily > be c:\1507\Mozilla Firefox", depending on how use used the installer) > > if someone did a custom install originally, the easily think that they were > installing Fx 2.0 on top of 18.104.22.168, but really they weren't, leaving them with > both Fx 22.214.171.124 and 2.0. I can dream up a scenario where they think they are > running Fx 2, but they really start up 126.96.36.199 (from an old shortcut), and then > get prompted for the 188.8.131.52 upgrade. > "if someone did a custom install originally, the easily think that they were installing Fx 2.0 on top of 184.108.40.206, but really they weren't" That is a fair assessment. However, when I did the manual install of 2.0, I made sure it went into the same directory as 220.127.116.11. In addition, after restarting FireFox, using the same old icon, I went into Help > About, and the version displayed in the About dialog box was 2.0. After the autmated update, I used the same old icon again, and went directly to the Help > About dialog only to find 18.104.22.168. But I will check my PC to validate if the autmated updater installed 22.214.171.124 in a separate directory.
Harris' case: This user had installed Russian Firefox 2.0 onto his most likely Russian 126.96.36.199, and some time later got a message upon restart, saying that the 2.0 to 188.8.131.52 update was successful. Since then, that 2.0 install is working well. OS: Windows XP Pro SP2 Help->About: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1) Gecko/20061010 Firefox/2.0 about:: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1) Gecko/2006101023 Firefox/2.0 He's uncertain about his 1.5's history. Originally it was 184.108.40.206, then it has been either updated to 220.127.116.11 or 18.104.22.168 has been installed over it. Then 22.214.171.124 was automatically updated to 126.96.36.199. update.xml is present, and the URLs there include <https://aus2.mozilla.org/update/1/Firefox/188.8.131.52/2006072814/WINNT_x86-msvc/ru/release/update.xml>, <http://download.mozilla.org/?product=firefox-184.108.40.206-complete&os=win&lang=ru> and <http://download.mozilla.org/?product=firefox-220.127.116.11-partial-18.104.22.168&os=win&lang=ru> -- it also mentions 22.214.171.124 several times. Error console and LiveHTTPHeaders both say: https://aus2.mozilla.org/update/2/Firefox/2.0/2006101023/WINNT_x86-msvc/ru/release/Windows_NT%205.1/update.xml
Harris' case (continued): 2.0 has been installed into the same directory where 126.96.36.199 was. 2.0 has been used for some time before the accident. "Automatically download and install the update" (don't ask the user) was enabled. On one day, when the 188.8.131.52 update was released, Harris started his 2.0 up and got a message that said it was necessary to restart due to the update to 184.108.40.206. No 2.0 (or Firefox at all) has been installed later.
Harris' case: My mistake: it didn't say the update was successful, it said that the download has finished. AFAHR, it also didn't say anything after the restart.
12 years ago
Unfortunately I have not been able to reproduce this on the Mac. We had reports on IRC that Mac users had hit this bug, and that makes me a bit uneasy because we don't have any information in this bug about those incidents. (In reply to comment #7) > I will try some testing on Mac. I have some good profiles that have been back > and forth between 1.5.0.x and 2.0. >
Created attachment 245527 [details] [diff] [review] v1, server component to ignore malformed AUS URIs This should ignore 1.5.0.x clients posing as 2.0 clients by switching off the URI schema (2) and comparing that with the %OS_VERSION% passed. It will break (show no updates) if the %OS_VERSION% parameter is null, literal (passed as %OS_VERSION%), or if the client version is not /^2.*$/ (eliminating the possibility of the 2/Firefox/1.5.0.x scenario). The conditionals are based on discussions between preed, morgamic and sspitzer. We aren't sure if this is the way we want to address the problem (by cutting off the update at the source) but it is a proposed solution. We are still missing the other possible scenario -- a v1 URI schema with a 2.0 version -- which is basically a 1.5.0.x build thinking it's 2.0.0.x.
Attachment #245527 - Flags: review?(preed)
Comment on attachment 245527 [details] [diff] [review] v1, server component to ignore malformed AUS URIs I'd put a bigger "XXX: if Firefox 1.5.0.x ever moves to version 2 URI schemas, this will break!" in the comments, but yeah... looks good. Let the downgradage of the horked builds cease!
Attachment #245527 - Flags: review?(preed) → review+
!preg_match('/^2.*$/',$clean['version']) what about 3.x (and/or minefield nightly?)
(In reply to comment #29) > !preg_match('/^2.*$/',$clean['version']) > > what about 3.x (and/or minefield nightly?) Hrm... morgamic: might it make more sense to single out 1.5.x specifically for this hack, i.e. preg_match('/1\.5.*/, $clean['version'])?
Yeah, we might want to just cover the 1.5.0.x cases, since that is more close-ended.
Aleksej R. Serdyukov, thanks for the details about Harris' scenario (comments #23, #24 #25) I'm not convinced (from your comments) that Harris did the "install on top of a running version" scenario that Nick suggested (comment #20), which makes me nervous. We are still searching for a different scenario (besides comment #20) to cause this problem. If we can figure one out, let's start a new bug.
Assignee: nobody → morgamic
Created attachment 245797 [details] [diff] [review] v2, to cover only 1.5.* ++r=preed
Attachment #245797 - Flags: review?(sspitzer)
Comment on attachment 245797 [details] [diff] [review] v2, to cover only 1.5.* r=sspitzer (mike, in the comment above, should we change: "/update2/2/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION/update.xml" to "/update2/2/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/update.xml"?
Attachment #245797 - Flags: review?(sspitzer) → review+
mike/preed: also, if we do any sort of logging or metrics from this php code, could we add a log item before the break, so we could keep track of how often this happens?
*** Bug 360535 has been marked as a duplicate of this bug. ***
Fix went in today; sspitzer verified that updates are no longer being served for (unfortunately already-horked) clients with invalid AUS requests.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Component: General → General
Keywords: fixed220.127.116.11, fixed18.104.22.168
Product: Firefox → AUS
QA Contact: general → general
Version: unspecified → 2.0
juan, if you looking for a test cases to verify morgamic's changes to AUS (specifically, the change covered by his "v2, to cover only 1.5.*" https://bugzilla.mozilla.org/attachment.cgi?id=245797 above), here's some tests: GOOD (you should get a snippet) https://aus2.mozilla.org/update/1/Firefox/22.214.171.124/2006090918/WINNT_x86-msvc/en-US/release/update.xml BAD (you should get an empty snippet) https://aus2.mozilla.org/update/2/Firefox/126.96.36.199/2006090918/WINNT_x86-msvc/en-US/release/update.xml (because version "2" is not allowed for 1.5.*) GOOD (you should get a snippet) https://aus2.mozilla.org/update/2/Firefox/188.8.131.52pre/2006112803/WINNT_x86-msvc/en-US/nightly/Windows_NT%205.1/update.xml BAD (you should get an empty snippet) https://aus2.mozilla.org/update/2/Firefox/184.108.40.206pre/2006112803/WINNT_x86-msvc/en-US/nightly//update.xml (version is empty) BAD (you should get an empty snippet) https://aus2.mozilla.org/update/2/Firefox/220.127.116.11pre/2006112803/WINNT_x86-msvc/en-US/nightly/%25OS_VERSION%25/update.xml (version is %OS_VERSION%)
Verified using testcases in comment #38.
Status: RESOLVED → VERIFIED
Keywords: fixed18.104.22.168, fixed22.214.171.124 → verified126.96.36.199, verified188.8.131.52
Whiteboard: [need testcase]
You need to log in before you can comment on or make changes to this bug.