User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091112 Thunderbird/3.0 Installed a fresh copy of Tb3 RC1 and came to uninstall it. Add or Remove Programs shows Mozilla Thunderbird () i.e. no version number. Screenshot to come. Reproducible: Always Steps to Reproduce: 1.Install Tb3 RC1 Actual Results: Mozilla Thunderbird () shown in Add/Remove programs Expected Results: Mozilla Thunderbird (3.0)

Shows Add/Remove programs problem

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091112 Thunderbird/3.0

I can confirm this does fail on en-GB however. Can anyone see if this happens on other locales?

Also reproducible with the en-GB build on Vista, FWIW.

(In reply to comment #3) > Can anyone see if this happens on other locales? I can confirm this behavior in .de yeah, looks fine in vista and XP en-us

Fr_fr exhibits the same issue.

I'm pretty sure I know what this is, but I need to test it before I can do a patch with confidence.

This is a regression from bug 481374 and affects all locales. I'll attach a patch in a moment that will fix this.

This fixes the issue by switching the mail/installer/windows files to use MOZ_APP_VERSION instead of a generated APP_VERSION AFAICT the issue was caused by the fact that APP_VERSION was being generated in mail/installer/windows/Makefile from cat on the version.txt file. However, mail/locales/Makefile calls into the windows installer makefile when repackaging the installer files but doesn't re-run the cat, so APP_VERSION is undefined there (alternately something is actually undefined there causing APP_VERSION not to get set). It appears Firefox doesn't have this issue because they define APP_VERSION in browser/locales/Makefile.in so the call across makefiles work (I'm not sure if this was on purpose or by accident, however for them it works). As APP_VERSION is a shell call to cat, which ends up with exactly the same version string as obtained from MOZ_APP_VERSION (in confvars.sh), I'm proposing that we save ourselves the issues of needing a define and cat in two different makefiles, and just use MOZ_APP_VERSION. I've tested this manually by following the buildbot steps using the repack log from the RC build and it worked fine from the installer perspective, all the current repacks (trunk + branch) have this bug so we can easily land and retest at each stage. Doing a test upgrade from fr 3b3 to fr rc1 also switched the registry entries to the incorrect version, so I expect automatic upgrades will work fine and restore the correct value once we apply this patch.

i installed shredder in jan or feb this year. using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5pre) Gecko/20091026 Shredder/3.0pre i see "Shredder (3.0pre)" with Windows Vista Business German in my "Programme and Funktionen" Control Panel. Cheers,

Comment on attachment 412557 [details] [diff] [review] The fix a=Standard8 for my own low risk patch that does some polish to l10n installers.

Checked in: http://hg.mozilla.org/comm-central/rev/e998e4a048b1 http://hg.mozilla.org/releases/comm-1.9.1/rev/de14f654ebce I'll be landing this on the appropriate relbranch within the next 12 hours.

Checked into relbranch for build 2 of RC1: http://hg.mozilla.org/releases/comm-1.9.1/rev/3f0b5a0455d9