gu-IN and pa-IN uninstall broken after update (Windows, FF+Tbird)




13 years ago
11 years ago


(Reporter: tracy, Unassigned)


({regression, smoketest})

1.8.0 Branch
Windows XP
regression, smoketest
Bug Flags:
blocking-firefox2 -
blocking1.8.0.4 -
blocking1.8.0.5 -

Firefox Tracking Flags

(Not tracked)





13 years ago
if you update from Thunderbird from 1.5 to, the gu-IN and pa-IN unistallers are broken.

The straight installed versions of 1.5 and uninstallers for those locales work fine.

-install 1.5
-update to

tested results:
The add/remove item for Thunderbird has been localised and fails to work. It can't find the uninstall log file.
Also, manually running the unistaller from the app dir fails

Expected results:
The add/remove item shows as unlocalised Thunderbird and unistalling works endign with bringing up the new survey dialog.

Didn't know where else to file this, Axel suggested here.

Comment 1

13 years ago
The suspect #1 mentioned on #developers is nsPostUpdateWin.js, updateRegistry.

This pulls the brandFullName from to set the registry key.
Which, at least that is the idea I have right now, is inconsistent with what
the installer and the uninstaller think.
That's why installers uninstall fine, updates don't, *IFF*:
the localization of brandFullName is not what the installer expects, which is
perfectly fine in the rest of the app.

Candidates for affected products/locales:
Thunderbird 1.5.0.x: gu-IN, pa-IN
Firefox ar, be (not released), gu-IN, pa-IN

For the Thunderbird builds, both gu-IN and pa-IN show the problem, and are
the only two locales that changed fullBrandName, tested with the releasetest 
update channel. The Firefox list is just a grep in the source to check possibly 
affected builds.

This is not a bug in the localizations for sure, the locales transcribed the
names of our product, which is perfectly fine. At least as long as the analysis
above is correct. CCing the owners to keep them informed.

Comment 2

13 years ago
This is an ugly problem some locales in FFx and TBird
Flags: blocking1.8.0.3?


13 years ago
Flags: blocking1.8.0.4+
Flags: blocking1.8.0.3?
Flags: blocking1.8.0.3-

Comment 3

13 years ago
There's an interesting side effect from these locales translate the brand name "Firefox" and "Thunderbird". We insert the brand name in the outgoing user-agent header for e-mail. So instead of seeing Thunderbird (Windows/20060308) in the user agent header for e-mail from these users, I instead see a group of non encoded illegal 8-bit characters in the mail header. 

Comment 4

13 years ago
I filed bug 334993 on the User-Agent issue.

Note that I'm pretty sure that nsIXULAppInfo one of the possible ways to
fix nsPostUpdateWin.js, or we can preprocess it.

Comment 5

13 years ago
Preprocess "it"? You can't preprocess nsPostUpdateWin with locale-specific information, that will break repackaging.

Comment 6

13 years ago
The point is that the app name part of the registry key must not be locale
specific. At least it is not in the installer nor the uninstaller.
It'd be good to have source references in both of these where they access registry
keys including the product name.

Comment 7

13 years ago
I'm almost positive the installer gets its information from installer.cfg

Comment 8

13 years ago
There are at least two ways to fix this: we could fix the installer to use the correct localized useragent string, or fix postupdate to know about the nonlocalized string that the installer knows about. I'm not certain which one is easier/better.
nsPostUpdateWin.js is all Darin -> reassigning from "nobody"
Assignee: nobody → darin
Summary: Tbird gu-IN and pa-IN updated Windows unistallers are broken → gu-IN and pa-IN uninstall broken after update (Windows, FF+Tbird)

Comment 10

13 years ago
There's also bug 339344, but I can reproduce that one without auto-update.
not sure an uninstall failure ever rises to the level of "blocker".
Severity: blocker → normal
Flags: blocking1.8.0.5+ → blocking1.8.0.5-
Darin, could we get this fixed for 2.0?
Flags: blocking-firefox2?

Comment 13

13 years ago
Axel: so, this bug exists in 2 as well?
Yes, this is an updater problem, IIRC, and not related to the installer.
The lxr link in the URL at least didn't change AFAICT on the 1.8 branch.
Not going to block on a problem involving bad translations of something that shouldn't be translated.
Flags: blocking-firefox2? → blocking-firefox2-

Comment 16

13 years ago
Can we just ask the localizers to NOT translate the brand name?  That will fix this problem too, right?

Why are people translating the brand names anyway?  I understand that some people will not be able to read "Firefox" and "Thunderbird" if it's not in their language, but do we have any policy on whether or not translating those words is ok?

mconner: If we are going to push for better l10n parity with en-US for 2.0, I would think we still need to think about what's best for this bug.  Granted, gu-IN and pa-IN are not P1 locales, but I think India is an important region to think about for the future, and we shouldn't just ignore issues with those users.
The indian locales don't translate the names, they transcribe it, IIRC, like the l10n trademarks policy says.
In addition, these changes are intended to be possible, it's just that the updater shouldn't pull the localized appname, but the appname from nsIXULAppInfo or what it's called. This is not a bug in the localizations, but a bug in the app exposed by the localizations.
Renominating for consideration of Axel's comments ("use nsIXULAppInfo")
Flags: blocking-firefox2- → blocking-firefox2?
We're not sure that this is a problem with the new NSIS installer, and these aren't tier 1 locales, so we're not going to block on this.

cc'ing phik and cbeard to keep 'em in the loop.
Flags: blocking-firefox2? → blocking-firefox2-
Both pa-IN and gu-IN use English as installer language, due to font issues.

Thus, even if the installer would localize the product name (which it doesn't), it would be the English names.

Of course, we haven't done any updates post-NSIS, but this is, again, not an installer bug. If the installer would use the localized name for registry keys, that'd be a different bug, as we (silently?) agreed that having localized names in registry keys isn't helping anybody.

Comment 22

12 years ago
-> reassign to default owner
Assignee: darin.moz → nobody

Comment 23

12 years ago
For Gujarati (gu-IN), i have modified all brand names (Firefox/Thunderbird/Mozilla) to english in CVS (MOZILLA_1_8_BRANCH). Please let me know, if the build still fails.
Ankit, that check-in didn't have a patch, let alone an approved patch. The branch is frozen, please attach a patch corresponding to your check-in to a new bug and request approval1.8.1.5. Attaching it to this bug won't do.


12 years ago
Depends on: 384013


11 years ago
Product: Firefox → Toolkit
This shouldn't be a problem in 1.8.1 and above... 1.8.0 is EOL. Can this be resolved -> wontfix or sumthin?


11 years ago
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.