Closed
Bug 39367
Opened 25 years ago
Closed 24 years ago
InstallTrigger.installChrome failed to install & select locale
Categories
(SeaMonkey :: Installer, defect, P3)
SeaMonkey
Installer
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: tao, Assigned: dveditz)
References
()
Details
(Keywords: verifyme, Whiteboard: [nsbeta2+] ETA: 7/20)
Attachments
(2 files)
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.
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.
Assignee | ||
Comment 5•25 years ago
|
||
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.
Status: NEW → ASSIGNED
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.
Assignee | ||
Updated•24 years ago
|
Whiteboard: [nsbeta2+] → [nsbeta2+] ETA: 7/18
Assignee | ||
Comment 8•24 years ago
|
||
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.
Summary: InstallTrigger.installChrome() failed to install & select locale → InstallTrigger.installChrome failed to install & select locale
Whiteboard: [nsbeta2+] ETA: 7/18 → [nsbeta2+] ETA: 7/20
Assignee | ||
Comment 9•24 years ago
|
||
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 10•24 years ago
|
||
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:"
Assignee | ||
Comment 11•24 years ago
|
||
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");
Reporter | ||
Comment 12•24 years ago
|
||
Yes, the attached xul file is not a good test case. Please follow dan's
suggestion to verify the fix.
Comment 13•24 years ago
|
||
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.
Reporter | ||
Comment 14•24 years ago
|
||
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•24 years ago
|
||
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
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•