Closed Bug 360127 Opened 18 years ago Closed 18 years ago

Firefox 2 auto update offers update for Firefox 1.5.0.8

Categories

(AUS Graveyard :: General, defect)

Product:
AUS Graveyard
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
4.x (triaged)

People

(Reporter: pvillanu, Assigned: morgamic)

References

Details

(Keywords: verified1.8.0.9, verified1.8.1.1)

Attachments

(3 files, 1 obsolete file)

Updates.xml file from this user running Firefox 2 and get auto-update offers for 1.5.0.8
942 bytes, text/xml
Details
the snippet saved locally from my hybrid 2.0-1.5.0.7 firefox as a result of upgrading, switching users, and not quitting
978 bytes, application/xml
Details
v2, to cover only 1.5.*
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 1.5.0.8
pvillanu@stern.nyu.edu, 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 1.5.0.8 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 -> 1.5.0.8. 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 1.5.0.7 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?
Flags: blocking1.8.1.1?
Flags: blocking1.8.0.9?
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 1.5.0.7 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 1.5.0.8" 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 -> 1.5.0.8 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...
(In reply to comment #14)
> Created an attachment (id=245199) [edit]
> Updates.xml file from this user running Firefox 2 and get auto-update offers
> for 1.5.0.8

Unfortunately that looks like a normal 1.5.0.6 -> 1.5.0.7 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 1.5.0.6 -> 1.5.0.7), 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/1.5.0.6/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 1.5.0.7 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 1.5.0.7 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:1.8.0.7) Gecko/20060909 Firefox/2.0
and at about: is 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) 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 1.5.0.8.
Flags: blocking1.8.1.1?
Flags: blocking1.8.1.1+
Flags: blocking1.8.0.9?
Flags: blocking1.8.0.9+
From the something-I-tried-but-didnt-help-figure-out-a-test-case dept:

I installed 1.5.0.7, got the update for 1.5.0.8 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 1.5.0.7, 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 1.5.0.7 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 1.5.0.7, but really they weren't, leaving them with both Fx 1.5.0.7 and 2.0.  I can dream up a scenario where they think they are running Fx 2, but they really start up 1.5.0.7 (from an old shortcut), and then get prompted for the 1.5.0.8 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:1.8.0.7 ... Gecko/20060909 Firefox/2.0".'

I jumped through the hoops to get into that state (install 1.5.0.7 as admin user X, leave 1.5.0.7 up and running, switch to admin user Y, install Fx 2.0 on top of 1.5.0.7, quit Fx 2.0, switch back to admin user X, start Fx back up, and you are in the dreaded 'rv:1.8.0.7 ... Gecko/20060909 Firefox/2.0' state)

from there, software update menu item is disabled, but I was able to force it and get a 1.5.0.8 update!

from the update snippet:

serviceURL="https://aus2.mozilla.org/update/2/Firefox/1.5.0.7/2006090918/WINNT_x86-msvc/en-US/release/null/update.xml"

note, the update version is "2" but the fx version is 1.5.0.7, proof that something is bad.

I'll attach the full snippet.


(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 1.5.0.7 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 1.5.0.7, but really they weren't, leaving them with
> both Fx 1.5.0.7 and 2.0.  I can dream up a scenario where they think they are
> running Fx 2, but they really start up 1.5.0.7 (from an old shortcut), and then
> get prompted for the 1.5.0.8 upgrade.
> 

"if someone did a custom install originally, the easily think that they were
installing Fx 2.0 on top of 1.5.0.7, 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 1.5.0.7.  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 1.5.0.8.  But I will check my PC to validate if the autmated updater installed 1.5.0.8 in a separate directory.
Harris' case:

This user had installed Russian Firefox 2.0 onto his most likely Russian 1.5.0.7, and some time later got a message upon restart, saying that the 2.0 to 1.5.0.8 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 1.5.0.5, then it has been either updated to 1.5.0.6 or 1.5.0.6 has been installed over it. Then 1.5.0.6 was automatically updated to 1.5.0.7.

update.xml is present, and the URLs there include <https://aus2.mozilla.org/update/1/Firefox/1.5.0.6/2006072814/WINNT_x86-msvc/ru/release/update.xml>, <http://download.mozilla.org/?product=firefox-1.5.0.7-complete&amp;os=win&amp;lang=ru> and <http://download.mozilla.org/?product=firefox-1.5.0.7-partial-1.5.0.6&amp;os=win&amp;lang=ru> -- it also mentions 1.5.0.7 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 1.5.0.7 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 1.5.0.8 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 1.5.0.8.
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.
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.
> 


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
++r=preed
Attachment #245527 - Attachment is obsolete: true
Attachment #245797 - Flags: review+
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
Closed: 18 years ago
Resolution: --- → FIXED
No longer blocks: 360535
Flags: review+
Keywords: fixed1.8.0.9, fixed1.8.1.1
Product: Firefox → AUS
QA Contact: general → general
Version: unspecified → 2.0
Whiteboard: [need testcase]
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/1.5.0.7/2006090918/WINNT_x86-msvc/en-US/release/update.xml 

BAD (you should get an empty snippet)
https://aus2.mozilla.org/update/2/Firefox/1.5.0.7/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/2.0.0.1pre/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/2.0.0.1pre/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/2.0.0.1pre/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: fixed1.8.0.9, fixed1.8.1.1 → verified1.8.0.9, verified1.8.1.1
Whiteboard: [need testcase]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: