Some menu items are missing if you use incompatible profiles

VERIFIED FIXED in mozilla0.9.3


Core Graveyard
Profile: BackEnd
17 years ago
2 years ago


(Reporter: Katsuhiko Momoi, Assigned: David P. Drinan)


Windows 2000
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+], r=jbetak,sr=hyatt, verified on branch)


(14 attachments)



17 years ago
** Observed with 6/15/2001 Win32 build **

This problem has caught the attention of many users
who downloaded Netscape 6.1 and tried to use an earlier
profile such as the ones from 6.01 or earlier Mozilla
builds. This occurs frequently enough that the's
Windows shareware site mentions this as part of their review
of NS 6.1. 
This problem is shared by all Mozilla browsers, however.

Here's one typical scenario:

1. The user cerated a profile under NS 6.0 or NS 6.01
   and used it a while.
2. The user downloads NS 6.1 build and since there is 
   one profile created by NS 6.x on the user's system,
   NS 6.1 starts up on the old profile.
3. But when the user looks at menu items uder File, View, etc.
   some of the menu items are missing.

I believe, Mozilla caches some UI items under a profile
directory. Now if the user uses an incompatible profile,
the present menu structure may conflict with the 
cached ones and this possibly will lead to the
I have seen this problem happen under 2 sets of 

1. Using a profile from an earlier version which 
   had quite a different organizaiton of menu items.
2. Using the same version but it just so happens that
   the profile is currently set for another language than
   the newly installed build's default language.

This is realy a big problem and some press articles 
report it as if it were un-fixable defect.
You can avoid this problem by creating a new profile.
But most people want to use the old profile which has
associated bookmarks, mail folders, etc. Adn it does not
occur to most people that they cannot use an older profile.
It does not work that way for Communicator. For example,
incompatible profiles can be migrated but are not usable. 

We need similar kind strategy for Mozilla.
This is a chrome or internationalization problem. I have used profiles made with
6.0 with current builds without problems. For me though, the old and new
profiles are the same locale so maybe that's why I didn't see it. Something has
changed with locales between 6.0 and current builds. If you look in
bin/defaults/profile/, the contents are slightly different. For US, the locale
sub dir in 6.0 is called "en-US" In current builds, it's called "US" Those dirs
are only used when the profile is first created so it shouldn't have any effect
here. But the fact that something changed here between old and new makes me
wonder. CC'ing tao about this. 

Comment 2

17 years ago
FYI, Tao is on sabbatical, returning in a couple(?) weeks.

momoi> 3. But when the user looks at menu items uder File, View, etc.
momoi>    some of the menu items are missing.

Kat, Please be more specific about which items are missing.

ccarlen> For US, the locale sub dir in 6.0 is called "en-US" In current
ccarlen> builds, it's called "US" Those dirs are only used when the profile
ccarlen> is first created so it shouldn't have any effect here. But the fact
ccarlen> that something changed here between old and new makes me wonder.

I don't know the specifics, but in general Tao's changes were to separate
UI from content.  For content he uses "US" and for UI he uses "en-US"
(e.g. chrome/en-US.jar).

Comment 3

17 years ago
momoi> 3. But when the user looks at menu items uder File, View, etc.
momoi> some of the menu items are missing.

bobj >Kat, Please be more specific about which items are missing.

Unfortunately, what items are missing seem to be entirely
dependent on particular profile data. So it is not
useful for me to say item X, Y, and Z are missing.

Also as I said before, this is not just due to
using a profile created for one language under
another language profile. In fact many of the reprots
are coming from people who have used only English versions.
In some cases, you really have to look closely to find 1 or 2 items missing from
the menus. 

Comment 4

17 years ago
I am guessing that one way to approach this problem
is to ask first what UI items are being cached and where.
(Can hyatt help here?)

Then work backwards logically to see how that caching
mechanism might be reflected when incompatible profiles
are used.

Comment 5

17 years ago
Adding lbaliman to cc-list;  nominating nsbeta1, nsbranch

Other people are also experiencing missing pieces of UI in Edit/Preferences
Keywords: nsbeta1, nsBranch


17 years ago
Severity: normal → critical

Comment 6

17 years ago
I'd suggest someone create one Japanese profile w/6.01 and another Japanese
profile w/6.1PR1.  Then diff all the files in the 2 profiles, especially
the files in the chrome subdirectory.

And do the same for the US-English profiles, because we should understand
why these work.

Comment 7

17 years ago
Adding nscatfood keyword (press feedback bug)
Keywords: nsCatFood

Comment 8

17 years ago
I can reproduce the diffs for US profiles in 6.0/ 6.1PR1 but I have no way to 
soft copy. (using merge.exe from araxis) will try to add img files

Comment 9

17 years ago
Bhuvan - Any action on this?

Comment 10

17 years ago
Created attachment 40089 [details]
diff of 6.0/6.1 profile directory- jpeg of diffs(p1)

Comment 11

17 years ago
Created attachment 40090 [details]
profile diffs (2nd half) 6.0/6.1profile

Comment 12

17 years ago
Grace, Please provide a diff of the *.rdf files under the chrome directory.

Comment 13

17 years ago
Created attachment 40140 [details]
user-locale.rdf 6.0 profile

Comment 14

17 years ago
Created attachment 40142 [details]
user-skins.rdf file for 6.0 profile

Comment 15

17 years ago
Created attachment 40144 [details]
user-locales.rdf file for 6.1 profile

Comment 16

17 years ago
Created attachment 40146 [details]
user-skins.rdf file for 6.1 profile

Comment 17

17 years ago
user-skins.rdf is very different between the 6.0 and 6.1 profiles.

Does someone understand these differences?
Does 6.1 understand the 6.0 users-skins.rdf?

*** 60-user-skins.rdf	Tue Jun 26 13:54:58 2001
--- 61-user-skins.rdf	Tue Jun 26 13:55:08 2001
*** 1,13 ****
  <?xml version="1.0"?>
!      xmlns:RDF="">
    <RDF:Description about="urn:mozilla:package:messenger">
!     <NS593:selectedSkin xmlns:NS593="" 
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:aim">
!     <NS594:selectedSkin xmlns:NS594="" 
    <RDF:Description about="urn:mozilla:package:navigator">
!     <NS595:selectedSkin xmlns:NS595="" 
--- 1,13 ----
  <?xml version="1.0"?>
! <RDF:RDF xmlns:c=""
!          xmlns:RDF="">
    <RDF:Description about="urn:mozilla:package:messenger">
!     <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:messenger"/>
    <RDF:Description about="urn:mozilla:package:navigator">
!     <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:navigator"/>
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:aim">
!     <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:aim"/>

Comment 18

17 years ago
user-locales.rdf looks very similar between the 6.0 and 6.1 profiles.

Some of the lines have been reordered and 6.1 adds the 2 lines:
  <RDF:Description about="urn:mozilla:package:messenger-region">
  <c:selectedLocale resource="urn:mozilla:locale:US:messenger-region"/>

Here is the complete diff:
*** 60-user-locales.rdf	Tue Jun 26 13:53:26 2001
--- 61-user-locales.rdf	Tue Jun 26 13:53:46 2001
*** 10,28 ****
    <RDF:Description about="urn:mozilla:package:wallet">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:wallet"/>
!   <RDF:Description about="urn:mozilla:package:cookie">
!     <c:selectedLocale resource="urn:mozilla:locale:en-US:cookie"/>
    <RDF:Description about="urn:mozilla:package:messenger">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:messenger"/>
    <RDF:Description about="urn:mozilla:package:help">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:help"/>
    <RDF:Description about="urn:mozilla:package:net2phone">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:net2phone"/>
-   </RDF:Description>
-   <RDF:Description about="urn:mozilla:package:aim">
-     <c:selectedLocale resource="urn:mozilla:locale:en-US:aim"/>
--- 10,31 ----
    <RDF:Description about="urn:mozilla:package:wallet">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:wallet"/>
!   <RDF:Description about="urn:mozilla:package:messenger-region">
!     <c:selectedLocale resource="urn:mozilla:locale:US:messenger-region"/>
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:aim">
!     <c:selectedLocale resource="urn:mozilla:locale:en-US:aim"/>
    <RDF:Description about="urn:mozilla:package:messenger">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:messenger"/>
+   <RDF:Description about="urn:mozilla:package:cookie">
+     <c:selectedLocale resource="urn:mozilla:locale:en-US:cookie"/>
+   </RDF:Description>
    <RDF:Description about="urn:mozilla:package:help">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:help"/>
    <RDF:Description about="urn:mozilla:package:net2phone">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:net2phone"/>

Comment 19

17 years ago
There is no profile migration or any profile code involved here. This seem to
have arrived from the chrome dir related changes we did between 6.0 and 6.1. I
think Tao is the right owner for this bug as worked on several language pack
issues. Looks like he is still on Sabbatical. Bob Jung, let us know if his
return any where closer. Until then, ben probably knows the best about what has
been going on with chrome dir. Reassigning to him.

Adding hewitt to the cc list, if he has any comments about difference in
user-skins files.

Assignee: racham → ben


17 years ago
Target Milestone: --- → mozilla0.9.3


17 years ago
Keywords: nsbeta1, nsCatFood → nsbeta1+, nsCatFood+
Priority: -- → P1
1) Humour me and list which menu items are missing (even if this appears to change)
2) Could this be related to the region package stuff introduced since 6.0? I
talked to hyatt and he says he knows nothing of this change...

Comment 21

17 years ago
changing qa contact to jonrubin. jonathan, can you answer ben's questions?
QA Contact: gbush → jonrubin

Comment 22

17 years ago
I will list the missing menu items hopefully soon.  I tried an initial test to
see the missing items, but the test failed because I already had existing
profiles from 6.1b.  I installed 6.01 (US), created a profile, and then set that
profile to the Ja language pack.  When I tried opening the profile in
06-28-06-0.9.2, the browser immediately crashed (I submitted several Talkbacks
for this).  When I originally created the profile in 6.01, I opened it with no
problem in 6.1b (while the profile was still set to the En language pack); no
menu items were missing at all.

I'm cleaning my system right now so that I can create a profile in 6.01 and have
it auto-migrated to 6.1.  I'll give an update soon...

Comment 23

17 years ago
I still cannot open the 06-28-06 branch build using a profile set to the Ja lang
pack in 6.01-US.  This time, I installed 6.01 on a clean WinMe-Ja machine that
had never had 6.1 installed.  I created a profile, downloaded the Ja lang pack,
and then set the profile language to Ja.  When I installed 06-28-06, I got the
following error upon launch:

XML Parsing Error: undefined entity
Location: chrome://navigator/content/navigator.xul
Line Number 226, Column 32:

<menuitem accesskey="&addCurPageAsCmd.accesskey;" key="addBookmarkAsKb"

The missing menu items problem that others are reporting sounds similar to what
I reported in Bug 88163 (originally Bugscape 5802).  Since I can reproduce that
bug, I will indicate in my next comment what items are missing per that bug.

Comment 24

17 years ago
cc jbetak

Comment 25

17 years ago
I installed 06-21-11-0.9.1 Ja, created a profile, and then launched
06-28-06-0.9.2 using the Ja profile.  Here's what was missing from the menu:
(note that all menu headings appeared okay)

File: Send Page, Send Link
Edit: Prefill Form, Save Form Data, View Saved Data
View: nothing missing
Search: nothing missing
Go: nothing missing
Bookmarks: no Personal Toolbar Folder (in this case, there is no blank space
where it should appear)
Tasks: Mail, Instant Messenger
Help: nothing missing

Note that in the case where items are missing, it is still possible to click
where the text should be; in other words, the menu items are still functional. 
I will attach a couple screenshots of what the menu looks like.

Note that after creating a profile in 6.1b-en and opening in 6.1b-ja, when I
opened the same profile again in 6.1b-en, different items were missing (even
though it was an English profile).  When I tried reproducing this with a second
profile, the missing items in the Ja build were the same as listed above, and
nothing was missing when I opened in the US build again.  Here's what was
missing in the first profile (on US build):

File, Edit, View, and Help headings were missing.  Under each heading, the
following was missing:

File: New
  New: Navigator Window, Blank Page to Edit
Edit: Undo, Cut, Copy, Paste, Delete, Select All, Preferences
View: Nothing missing (just the View heading was missing)
Search: Everything under Search the Web missing (there wasn't even blank space)
Go: Nothing missing
Bookmarks: Nothing missing (Even Personal Toolbar Folder appears)
Tasks: Nothing missing
Help: About Plug-ins, About Netscape 6 missing

Now for the attachments...

Comment 26

17 years ago
Created attachment 40566 [details]
Missing File menu items

Comment 27

17 years ago
Created attachment 40567 [details]
Personal Toolbar Folder missing

Comment 28

17 years ago
Please try this.
 - Save the user-locales.rdf and users-skins.rdf files under the chrome/ 
   subdirectory in your 6.0 profile.
 - Copy the the 6.1 versions into the 6.0 profile.
 - Launch 6.1 with the 6.0 profile.

If it works then we've narrowed it down the the chrome files.  Then restore
the 6.0 user-locales.rdf file and try again.

When you reproduced this with en-US profiles, did you have the same missing
items that Jon described in his previous comment?

Comment 29

17 years ago
I created profiles with 6.0 and 6.01 RTM en-US builds.
I started 6.1 PR1 with both and did not see any problems.

Comment 30

17 years ago
This has been approved by PDT as a nsBranch PR1, meaning that this should be 
fixed in the Limbo build and marked as high priority for this build.  It was 
felt that this shouldn't hold up the candidate build for this week.  But, since 
the Limbo build was a high probability to be used for Netscape RTM this should 
be fixed in the Limbo build.

Comment 31

17 years ago

My findings are the same as yours for en-US builds.  However, if I copy the
user-locales.rdf and users-skins.rdf files from the ja-JP profile I created in
the Japanese build to the chrome dir of the en-US 6.01 build, the menu items
appear in English, but there are missing menu items as follows (all menu
headings appear okay):

File: Send Page, Send Link
  New: Message, Address Book Card, Instant Message
  Print Plus: Everything missing (can't even see blank areas)
Edit: Prefill Form, Save Form Data, View Saved Data
View: Nothing missing
Search: Nothing missing
Go: Nothing missing
Bookmarks: Imported IE Favorites appears twice
Tasks: Mail, Instant Messenger missing
  Privacy and Security: Everything missing (blank areas and arrows appear)
Help: Nothing missing


Comment 32

17 years ago
I got slightly different results than Jon:

I used 6.01 Ja RTM to create a new profile.
Then I started 6.1 JA PR1 with the profile created above.
 - File menu entries for Send Page, Send Link DO appear (in Japanese).
   (Different results than Jon.)
 - Edit menu entries for Prefill Form, Save Form Data, View Saved Data so
   appear BLANK.  I tried the blank entry for View Saved Data and it did
   open the dialog.  (Same as Jon's results.)
 - Task menu entries for Mail, Instant Messenger DO appear (in English as
   they do running 6.1 Ja PR1)  (Different results than Jon.)

Comment 33

17 years ago
> My findings are the same as yours for en-US builds.  However, if I copy the
> user-locales.rdf and users-skins.rdf files from the ja-JP profile I created in
> the Japanese build to the chrome dir of the en-US 6.01 build, the menu items
> appear in English, but there are missing menu items as follows (all menu
> headings appear okay):

They might be appearing in English because the Japanese jar files are not
installed in the directory that you installed the US build.

Comment 34

17 years ago
Here is my guess regarding what is happening.

When you upgrade from 6.0 to 6.1, I will do an overwrite in the chrome registry
of all the dynamic overlays that should be loaded.  I do not however, do any
sort of removal of "stale" dynamic overlays.

I am guessing that the code that walks through the list of dynamic overlays is
bailing when it tries to load a non-existent old overlay that is no longer in
the JAR.

I could be completely wrong, but that's a best guess.

Comment 35

17 years ago
Ok, menu items being there but blank points to a locale problem, so that
contradicts my guess.

Comment 36

17 years ago
I created another new profile using 6.01 Ja RTM.

I started 6.1 Ja PR1 and again saw the blank Edit menus for Prefill Form,
Save Form Data, View Saved Data.  I quit.

I saved copies of the user-locales.rdf and user-skins.rdf and then replaced
them by copying from my 6.1 Ja PR1 profile.  Re-started 6.1 Ja PR1.
The Edit menus items appeared.  I quit.

I restored the profile's original user-locales.rdf and user-skins.rdf.
Re-started 6.1 Ja PR1.  The Edit menus items STILL appeared.

This could indicate that some stale info is not being removed.

After I quit, I noticed that user-locales.rdf had been updated.  Here is
the diff of before and after:

*** user-locales.rdf	Fri Jun 29 14:14:38 2001
--- orig/user-locales.rdf	Fri Jun 29 14:01:34 2001
*** 1,25 ****
  <?xml version="1.0"?>
! <RDF:RDF xmlns:c=""
!          xmlns:RDF="">
!   <RDF:Description about="urn:mozilla:package:cookie">
!     <c:selectedLocale resource="urn:mozilla:locale:ja-JP:cookie"/>
    <RDF:Description about="urn:mozilla:package:messenger">
!     <c:selectedLocale resource="urn:mozilla:locale:ja-JP:messenger"/>
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:net2phone">
!     <c:selectedLocale resource="urn:mozilla:locale:ja-JP:net2phone"/>
    <RDF:Description about="urn:mozilla:package:aim">
!     <c:selectedLocale resource="urn:mozilla:locale:ja-JP:aim"/>
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:wallet">
!     <c:selectedLocale resource="urn:mozilla:locale:ja-JP:wallet"/>
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:navigator-region">
!     <c:selectedLocale resource="urn:mozilla:locale:JP:navigator-region"/>
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:communicator-region">
!     <c:selectedLocale resource="urn:mozilla:locale:JP:communicator-region"/>
--- 1,13 ----
  <?xml version="1.0"?>
!      xmlns:RDF="">
!   <RDF:Description about="urn:mozilla:package:net2phone">
!     <NS5:selectedLocale xmlns:NS5="" 
    <RDF:Description about="urn:mozilla:package:messenger">
!     <NS6:selectedLocale xmlns:NS6="" 
    <RDF:Description about="urn:mozilla:package:aim">
!     <NS7:selectedLocale xmlns:NS7="" 
This bug doesn't seem like a Navigator bug. 

Comment 38

17 years ago
adding PDT+, Tao will also work on it
Whiteboard: [PDT+]
Blocks: 86445

Comment 39

17 years ago
Tao, please take a look at this one.


17 years ago
Blocks: 62177

Comment 40

17 years ago
Couple of findings:

1. Run US NS6.1b1 on profile, "ns6.01-ja", created by US NS6.01 -> all menu 
   items appeared.
2. Run US NS6.1b1 on profile, "ns6.01-ja", created by Ja NS6.01 -> menu items:
   "Send Page" & "Send Link" under "File" menu and "Mail" & "Instant 
   Messenger" under "Tasks" menu become blank.

   If I take out the "ns6.01-ja/xyz/chrome/user-locales.rdf" in the profile 
   created by Ja NS6.01 and re-run NS6.1b1, a new "chrome/user-locales.rdf" will
   be created and all missing menu items re-appear.

My theory is that "chromeRegistry" does not migrade user profile's 
"user-locales.rdf" properly when provider names are not recognized by the newer
client release. This would not be a locale-specific problem; theme packs suffer
the same problem, too. In fact, I suspect 84515 is a manifest of similar cause,

Assignee: ben → hyatt
No longer blocks: 62177

Comment 41

17 years ago
Created attachment 40998 [details] [diff] [review]

Comment 42

17 years ago
Created attachment 40999 [details]
The re-generated "ns6.01-ja/xyz/chrome/user-locales.rdf" by NS6.1b1

Comment 43

17 years ago
David, 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 44

17 years ago
Hyatt mail bounced, he's out of the office this week.  Can anyone on the CC list
do this checkin for him?

Comment 45

17 years ago
Who is the "virtual" Hyatt? Even we have a solution for this bug, I'd feel more
comfortable if he reviews the patch. Note that there is no proposed fix yet.

Comment 46

17 years ago
Hyatt will be back on monday, if we want it sooner someone else will have 
to review


17 years ago
Blocks: 62177
There is still no patch to review, this bug is unfixed. Is there anyone other
than Hyatt who could fix this problem? 

Comment 48

17 years ago
I couldn't reproduce this problem with Ja N6.1b1 running on profile created by
Ja N6.01. This is consistent with my experience with English build. 
tao: have you tried to install and run different language packs? That triggered 
very similar problems during my tests for bug 86445.

Comment 50

17 years ago
Yes, read my comments in 
--- Additional Comments From 2001-07-02 19:07 ----

I am gonna conclude that the problem happens when users run n6.1b1 over
a profile 

  1. created by a 6.0 or 6.01 release
  2. the locale preference was set to one that is not supported in n6.1b1.

Similar problem probably will happen to skin, too.


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


17 years ago
Whiteboard: [PDT+] No ETA → [PDT+] have fix, waiting for hyatt review on 7/9
no, I dont think this has a fix as of right now. I think we are waiting on Hyatt 
for the fix. all these attachments are not fixes. 

Comment 52

17 years ago
IMO, to fix this problem, we need to add logic to chromeRegistry code to 

  1. remove references (in user profile locale/skin) to not existing 
     providers (instead of simply converting the namespace.). Then,
  2. check if the version number of the package and provider matches; if not,
     throw it away, too. 
  3. To make the above work, we also need to add attribute, "localeVersion" 
     to all package & locale registration. This had been done for skins but
     not locale providers.

I should be more than happy to provide patches for (3). 


17 years ago
Whiteboard: [PDT+] have fix, waiting for hyatt review on 7/9 → [PDT+]
*** Bug 84515 has been marked as a duplicate of this bug. ***

Comment 54

17 years ago
Created attachment 41558 [details] [diff] [review]
add localeVersion to packages and locale providers

Comment 55

17 years ago
Created attachment 41559 [details] [diff] [review]
add localeVersion to NS chrome providers

Comment 56

17 years ago
Need r/sr for &

In my debug branch builds, the above two patches are sufficient to re-surface the
missing menu items. Reading the source code, it appears that chrome registry 
is doing (2) already. As to (1), chromeRegistry ignores (instead of remove)
references to not existing providers. 

Note that I assigned "0.9.2" as the branch build's locale version. Should we use
0.9.3 for trunk, then?
Whiteboard: [PDT+] → [PDT+], need r/sr=

Comment 57

17 years ago
These two patches could be applied to trunk by substituting "0.9.2" with "0.9.3".

Suggested test plan for QA (after we check in the patch)
1. Test 6.1 build over profile created by 6.1
  1.1 run new build to create new profile - testing chrome url conversion of 
      navigator[-region, global[-region, etc.
  1.2 select profile to open Browser Window and quickly run through 
      menus/menuitems in Navigator - testing packages navigator[-region, 
      -platform], messenger[-region, -platform], global[-region], etc.

      Make sure you run through extensions such wallet, cookie, and security 
      manager, etc.
  1.3 Examine Editor, AIM, Net2Phone UI/components to ensure the corresponding 
      chrome registry is a properly handled.

2. Test 6.1 build over profiles created by previously releases (6.0x). Repeat
3. Cross language testing - Run 6.1 US build over non-enUS profiles created
   by 6.0x build. Repeat 1.1-1.3.

Risk analysis:

  Regression could be caused by mismatching localeVersion. The symptom will the
  failure of opening the UI/components or missing menuitems associated with 
  the locale providers of the packages. In theory, whenever the mismatching
  happens, none of the UI assoicated with this package could be opened/displayed
  properly. The defects should easily identified. -> low risk if the above QA
  test plan is performed.


Comment 58

17 years ago

(I was just a little perplexed to find out, that the chrome registry part is 
already done -

Comment 60

17 years ago
I always implement locale features at the same time i do skin features.  In this
case, I implemented locale and skin versioning at the same time, but I left it
up to you guys to decide if/when you wanted to "upgrade" your locale versions.  
Aha! Thanks for clarifying this...

Comment 62

17 years ago
Thanks, folks, for the quick reviews. WIll check it in once the trunk open.
Whiteboard: [PDT+], need r/sr= → [PDT+], r=jbetak,sr=hyatt

Comment 63

17 years ago
Created attachment 41683 [details] [diff] [review]
patch for security module.

Comment 64

17 years ago
Patches (except secuirty module) checked into trunk. -> ddrinan
Assignee: hyatt → ddrinan

Comment 65

17 years ago
branch (except security) in, too. Note: the localeVersion for branch is "0.9.2",
while it is "0.9.3" for the trunk build.

Comment 66

17 years ago
Created attachment 41686 [details] [diff] [review]
patch for security module in branch.

Comment 67

17 years ago
Hi, David:

I suspect even with my patch, the problem could still be observed in running 
EN 6.1 over profile created with JA 6.1 language pack. The scenario might
escape the version checking logic. We'll need to verify this. 

Hi, Jon:

Would you add this into QA test plan:
1. Create a profile with newer JA 6.1 branch build. You probably need to get a
   set of JA langpacks from rchen to test this.
2. Run EN 6.1 on it.
3. Check if all UI are properly displayed. 


Comment 68

17 years ago
Checked in the security patches into trunk and branch.
tao, the changes to xpfe/browser/resources/content/unix/contents-platform.rdf
have a syntax error:

  <RDF:Description about="urn:mozilla:package:navigator-platform"
        chrome:displayName="UNIX Bindings"

Note the "/" on the opening tag...  At startup one gets the following message:

XML Error in file
'jar:resource:///chrome/comm.jar!/content/navigator-platform/contents.rdf', Line
Number: 16, Col Number: 5, Description: mismatched tag
Source Line:   </RDF:Description>

Comment 70

17 years ago
Nice catch, please see 90170. Strangely, it didn't break my fresh pulled Linux
build. Chromeregistry was generated properly as well. Anyway, patches had been 
reviewed and ready to go when tree is open.

Comment 71

17 years ago
Verified on branch using 07-10-05-branch on WinMe-Ja.  Verified according to
Tao's suggested test plan by creating enUS, enJP, jaJP, and jaUS profiles on
6.0x and 6.1, and jaJP profile on latest JA 6.1 branch build.  Opened each of
these profiles in 07-10-05-branch and did full check of UI.  Some observations:

1) Did not see ja UI in ja profiles; also did not see ja UI when switching to ja
language using View menu.
2) JP profiles showed only JP Sidebar and Bookmarks; Search, Home button, and
throbber remained set to US region.  This sounds similar to bug 90096, but the
original problem in 90096 can no longer be reproduced by following the steps
there (creating new US profile after downloading JP pack).
3) Could not switch to JP region via View menu--see bug 89531.
4) In Mail, Sort by Sender in View menu is blank.  Saw same problem in
07-09-05-branch, which predates Tao's patch.  Filed bug 90266.

The original problem reported in this bug--missing menu items--no longer occurs
on the branch.

Whiteboard: [PDT+], r=jbetak,sr=hyatt → [PDT+], r=jbetak,sr=hyatt, verified on branch

Comment 72

17 years ago
Filed bug 90279 for the UI problem in (1), and bug 90281 for the region problem
in (2).

Comment 73

17 years ago
The problems in bug 90279 and bug 90281 are probably due to Tao's localeVersion
patch, which he explained on 2001-07-08 19:24:

"Risk analysis:

  Regression could be caused by mismatching localeVersion. The symptom will the
  failure of opening the UI/components or missing menuitems associated with 
  the locale providers of the packages. In theory, whenever the mismatching
  happens, none of the UI assoicated with this package could be opened/displayed
  properly. The defects should easily identified. -> low risk if the above QA
  test plan is performed."

Tao and I made a tweak that "updated" the version of the packs that I was using;
after the tweak, I was able to change UI language and region.  I will further
confirm this when the packs themselves are updated.


Comment 74

17 years ago
CCing self.

I just recently found out through doing a clean install on a new machine that a
Spell Check icon is available in Mail Compose. At home I use a very old profile
that I've migrated up through the versions (from NS 4.70). The spell check icon
is not available on this migrated profile. I get the nightlies nightly
(currently running 2001071104), and even tried manually copying over the new
default locales to my profile. No worky. Is this part of this bug or something
entirely different?

Comment 75

17 years ago
I am marking this as fixed since all problems appeared to be gone. Let's
address future findings in new bugs. Also --> tao.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 76

17 years ago
Verified on trunk using 07-11-07-trunk on WinMe-Ja and WinXP-Ja.  (WinXP was
used for checking profiles created in 07-11-07-trunk and JA 07-05-06-branch,
WinMe was used for profiles created in 6.0x (had problems installing 6.0x on XP))

(One note, which may be completely unrelated: NS crashed on several occasions
when I would activate Mail from Tasks menu.  The crash usually would occur when
the account setup window would come up, so it doesn't look related to clicking
on the menu item itself.  Crash also occurred once when clicking on View>Sort by
in Mail, and twice when closing the Mail app.  Most of the time Mail didn't
crash at all.  In any case, I sent several talkbacks about 1 hour ago.)


Comment 77

17 years ago
The crashes may be related to bug 83785; I did not have any problems with
crashing when I verified on the branch.

Comment 78

17 years ago
i still do not see any spellcheck functionality on my nightly build (2001071204)

Comment 79

17 years ago
right doesn't have a spell checker. two people are working on this. 
if you'd like to help us,  please visit #mozilla and talk to 

Comment 80

17 years ago
*** Bug 88163 has been marked as a duplicate of this bug. ***

Comment 81

17 years ago
*** Bug 91817 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.