If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Non-default region does not load if selected in Profile Manager

VERIFIED FIXED

Status

SeaMonkey
General
P2
major
VERIFIED FIXED
17 years ago
13 years ago

People

(Reporter: Jon Rubin, Assigned: rchen)

Tracking

({intl})

Trunk
x86
Windows ME
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: No ETA)

Description

17 years ago
Tested on 6.1b build using WinMe-Ja.

Steps:
1) Start browser using default language and region settings.
2) Download new region pack as needed.
3) Close browser, restart, and create a new profile using a non-default region.
 After the browser opens, the default region will be loaded.

Note:  At this point, it is possible to switch to the non-default region, but it
cannot be loaded at the time of creating the new profile.



------- Additional Comments From jonrubin@netscape.com 2001-06-23 02:45:36 ----

Will the fix for Bugzilla 80230 fix this?



------- Additional Comments From rchen@netscape.com 2001-06-25 13:30:14 ----

Region pack issue.



------- Additional Comments From jonrubin@netscape.com 2001-06-25 15:41:56 ----

cc nhotta



------- Additional Comments From jbetak@netscape.com 2001-06-25 17:16:04 ----

Jon, 

Katakai fixed some backend issue chrome registry had with content pack 
switching, he also changed things at the profile file level. Naoki and I have 
tested his patch and (now speaking only for myself) I believe this should work 
as expected once Bugzilla 80230 has been resolved...



------- Additional Comments From jonrubin@netscape.com 2001-06-25 17:41:06 ----

Andreas, if no one objects, could you move this to Bugzilla?  Thanks.



------- Bug moved to this database by andreasb@netscape.com 2001-06-26 18:34 -------

This bug previously known as bug 6828 at http://bugscape.netscape.com/
http://bugscape.netscape.com/show_bug.cgi?id=6828
Originally filed under the Browser product and Localization-JA component.

Skipping unknown keyword: nsBranch.

Comment 1

17 years ago
Bringing over keywords from bugscape bug.
Keywords: intl, nsBranch

Comment 2

17 years ago
Marking as dependent on bug 80230.
Depends on: 80230

Comment 3

17 years ago
marking pdt+ after Friday's meeting with Frank and PDT
Whiteboard: [PDT+]

Comment 4

17 years ago
Bug 80230 is fixed, please test this with the latest branch build.

Comment 5

17 years ago
Tao, this is PDT+ bug. Tomorrow, on Tuesday, we'll try to build the
first RTM candidate. It would be good, if this could be resolved ASAP.

Comment 6

17 years ago
Jon, can you test if are still able to reproduce this since bug 80230 has been
fixed?

Comment 7

17 years ago
With N6.1b1 US build and installed JA region pack, I was able to reproduce the 
problem. However, my finding is that the regjp.xpi (dated 2001-06-07-13-0.9.1)
contains both JP and US profile directories:

Archive:  regjp.xpi
  inflating: bin/chrome/JP.jar       
  inflating: bin/defaults/isp/JP/aol.rdf  
  inflating: bin/defaults/isp/JP/nswebmail.rdf  
  inflating: bin/defaults/messenger/JP/Templates  
  inflating: bin/defaults/profile/JP/bookmarks.html  
  inflating: bin/defaults/profile/JP/chrome/userChrome.css  
  inflating: bin/defaults/profile/JP/chrome/userContent.css  
  inflating: bin/defaults/profile/JP/default-invite.rdf  
  inflating: bin/defaults/profile/JP/default-messages.rdf  
  inflating: bin/defaults/profile/JP/localstore.rdf  
  inflating: bin/defaults/profile/JP/mimeTypes.rdf  
  inflating: bin/defaults/profile/JP/panels.rdf  
  inflating: bin/defaults/profile/JP/search.rdf  
  inflating: bin/defaults/profile/us/bookmarks.html  
  inflating: bin/defaults/profile/us/default-messages.rdf  
  inflating: bin/defaults/profile/us/localstore.rdf  
  inflating: bin/defaults/profile/us/panels.rdf  
  inflating: bin/defaults/profile/us/search.rdf  
  inflating: bin/searchplugins/Netscape_Japan.gif  
  inflating: bin/searchplugins/Netscape_Japan.src  
  inflating: install.js
              
In addition, the profile/US directory in fact contain JP files. The result is
that the JP files in US directory overwrite the original US files and cause
all profiles created w/ US selection contain JP profile defaults.

To prove this theory, you can copy default/profile/{bookmarks.html, 
panels.rdf, etc} into profile/US and create a new profile with it. You should
be able to get the correct defaults.

->rchen
Assignee: tao → rchen
Status: NEW → UNCONFIRMED

Updated

17 years ago
Blocks: 62177

Comment 8

17 years ago
Hold on. I suspect something else is behind this problem. The region pack 
selection code might contribute to this problem as well. Perhaps, we should
log another bug against the regjp.xpi packaging problem. I am taking this
bug back for now and look into it more...
Assignee: rchen → tao
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 9

17 years ago
I tried it on a debug 2001-07-02 trunk build and couldn't reproduce this problem
if I have the correct files in both profile/{US,JP}. Could QA verify this with 
branch build? back to rchen :-)

thx
Assignee: tao → rchen

Comment 10

17 years ago
Note that I was able to create new profiles in this sequence

1. en-US UI, US region
2. en-US UI, JP region
3. en-US UI, US region

All created profiles have correct sidebar panels, bookmarks, and Search menu.
(Reporter)

Comment 11

17 years ago
Tao,

I checked this on both 07-03-06-0.9.2 and 07-03-11-trunk on WinMe-Ja.  I created
new profiles in the same sequence as you; however, I had different results (the
results were consistent between branch and trunk builds):

When I created the profile set to en-US UI, JP region, I noticed the following:

1) An activation window appeared, but it showed the Netscape Search page with
"Page Not Found".
2) View menu was disabled.
3) Home button was disabled.
4) Browser opened to blank page (location bar was blank); clicking on throbber
loaded correct Netscape.co.jp page, but location bar was still blank. 
5) I could not enter URLs in the location bar (I could type them in, but hitting
Enter had no effect); File>Open Web Location and File>Open File in the menu also
did not function.
6) Search menu categories and Bookmark menu folders did appear in Japanese.

When I then created a new profile set to en-US UI, US region (the third sequence
in your test), problems 1 - 5 went away; however, I noticed the following:

a) Sidebar was still set to JP region, even though this was a new profile that I
had set to US.  This sounds similar to bug 87939.
b) Search menu categories appeared in English, but Bookmark menu folders still
appeared in Japanese.

Note that the JP pack that I used was obtained via the View menu through
"Download More".  






No longer blocks: 62177

Comment 12

17 years ago
Jon:

The JP pack you got from the public ftp site is busted and will overwrite 
defaults/profile/US with JP files. I'll send you a good one. For other problems 
you observed, please log bugs separately.
(Reporter)

Comment 13

17 years ago
Tao,

I used your hacked JP pack with the 07-05-06 trunk and branch builds; problems
a) and b) from my last comment went away, but problems 1 - 5 still occurred in
the en-JP profile.  I will log separate bugs for those problems.  The original
problem reported in this bug does not occur with your hacked JP pack.

Updated

17 years ago
Whiteboard: [PDT+] → [PDT+] No ETA
(Assignee)

Comment 14

17 years ago
This is a Japanese localization bug. It will be fixed when we create the new
Japanese build. Please remove PDT+.

Comment 15

17 years ago
removing PDT+ since it will be fixed in the Japanese lang pack
Whiteboard: [PDT+] No ETA → No ETA

Updated

17 years ago
Blocks: 62177
(Assignee)

Comment 16

17 years ago
This should be fixed in JA 2001-07-05-06-0.9.2 Windows build. Please verify it.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 17

16 years ago
Jon, please check if the problem has been fixed.
(Reporter)

Comment 18

16 years ago
If I try to verify this bug now using the pack in the JA 2001-07-05-06-0.9.2
Windows build, I will run into the problems in bug 7060 thru bug 7065 on
pre-0710-branch builds, and the problem of bug 90281
(http://bugzilla.mozilla.org/show_bug.cgi?id=90281) on builds starting from
0710-branch.  Part of Tao's fix for bug 86807
(http://bugzilla.mozilla.org/show_bug.cgi?id=86807) requires that the pack's
localeVersion number match the client build's version, so I need to either apply
a tweak that "updates" the pack version in the 07-05 JA build, or use the pack
from the next JA build.

Ray, do you have an updated pack that I could use now?



(Reporter)

Comment 19

16 years ago
I tried the tweak, but ran into the Bugscape 7060 - 7065 problems.  Looks like I
will need to use a newer pack.
(Reporter)

Comment 20

16 years ago
Verified on WinMe-Ja using US Win 07-18-05-branch build and JP pack included
with JA Win 07-17-05-branch build.

Tao, the JP region now loads in new profiles, but I still get the problems in
Bugscape 7060 - 7065.  Is this because we are still using the PR1 region pack? 
If not, I need to reopen those bugs.
Status: RESOLVED → VERIFIED

Comment 21

16 years ago
Let's work together on this.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.