39367 - InstallTrigger.installChrome failed to install & select locale

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P3)

Description

[tao]

I just tested the InstallTrigger.installChrome() function in JS code. 
Here is what I got: 

     1. It downloaded the zip file into the user profile's "Chrome"
        directory but not unzipped.
     2. I didn't see it update either all-locales.rdf or user-locales.rdf.
     3. The client ran into a few assertions and then died.

The problem is reproducible on both NT and Linux w/ 05-15-2000 builds.

I am also attaching the localeSwitcher.xul and ja-JP.zip file.

Comment 1

[tao]

Attachment: localeInstaller.xul

Comment 2

[tao]

Attachment: ja-JP.zip

Comment 3

[tao]

To reproduce:

  1. place "localeInstaller.xul" in 
     "bin\chrome\packages\widget-toolkit\global\content"
  2. place "ja-JP.zip" in "bin\chrome".
  3. Launch mozilla and choose a profile, say "moz-m16-dbg".
  4. Load "chrome://global/content/localeInstaller.xul" from the 
     browser window,
  5. if you run into any assetion, ignore them...
  6. You shall see a dialog prompting whether to download and install the
     langpack, "ja-JP", click "OK"..
  7. You will see what I have described in the "Description" section
     of this bug report.

Let me know if you need help reproducing the bug.

Comment 4

[tao]

Thought that I added "nsbeta2" ? Add it now.

Comment 5

[Daniel Veditz [:dveditz]]

At one point using jar: URL's for chrome worked; the latest skins spankage 
seems to have changed this so I have to go back and explode the archives now.

I was hoping to avoid that, just use jar: URLs even though it would be slow 
until the caching was implemented. But now it's looking like I'll have to go in 
and explode the archives, and then switch it back later. Drat.

Comment 6

[tao]

Just for clarification: (1)in "Description field" is what I observed; 
not necessary a bug. I knew that the plan is to use jar which is not 
supposed to be "unzipped".

But, if we will not use JAR for PR2; yes, please unzip the zip archive unless
we can extra files from zip without decompressing it.

Comment 7

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 8

[Daniel Veditz [:dveditz]]

This actually works.  Right now I'm getting a crash at the end though :-(  but 
when restarting the chrome is correctly selected. I note that the new 
language-switcher menu item asks users to restart after switching so this may 
be a known bug.

Will take a brief look at the crash and then probably close this one.

Comment 9

[Daniel Veditz [:dveditz]]

I commented out the call to ReloadChrome() which was crashing. So now the 
locale can be installed and selected, but the selection will only take effect 
when new XUL is loaded. Generally on a restart, but if you hadn't loaded Mail 
(for example) you could open Mail and get the new locale.

Installing profile chrome appears to hide the globally-installed chrome of the 
same type (skin, locale or package). This is bug 45951 -- please vote for 
nsbeta2+ status for that bug.

Comment 10

[Grace Bush]

used testcase noted here-did not see the files all-locales.rdf and 
user-locales.rdf updated- should I? 
also when restarting with this profile I see an XML parsing error:undefined 
entity, line nubmer 141, column 29

accesskey="&reloadCmd.accesskey:"

Comment 11

[Daniel Veditz [:dveditz]]

I'm not sure the test case attached is still a valid one, but the XML error you 
described sounded like a UI thing, not a manifest.rdf parsing error. How far 
did you get into the process before the error?

I'm relatively sure Tao's XUL is not a good way to test since it clouds the 
results with uncertainty. I believe jimmy and/or david have test cases for 
installChrome, or you could write a simple HTML page that does the raw trigger:

InstallTrigger.installChrome(InstallTrigger.LOCALE, 
"url://to/locale/zip","name-of-locale");

Comment 12

[tao]

Yes, the attached xul file is not a good test case. Please follow dan's 
suggestion to verify the fix.

Comment 13

[timeless]

tao, do you think you could post a url for a new version of ja-JP or some other 
translation that works? [for once I wasn't the one who made the accesskey 
requirement]. Thanks.

Comment 14

[tao]

The ja-JP files I have at hand are not up-to-date. For Mozilla build, we rely
on MLP contributor to submit translations. Please see the project page in the 
URL field.

Also, I posted an instruction for making a ja-JP pack that Mozilla can use 
yesterday to news://news.mozilla.org/netscape.public.mozilla.l10n. 

Comment 15

[Grace Bush]

using the trigger as noted above, and after relaunching netscape 6, same parsing 
error is received- see bug 46534.
I think this bug is fixed- please reopen if it recurs