86807 - Some menu items are missing if you use incompatible profiles

Status: VERIFIED FIXED

(Core Graveyard :: Profile: BackEnd, defect, P1)

Description

[Katsuhiko Momoi]

** 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 Impress.co.jp'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
problem. 
I have seen this problem happen under 2 sets of 
circumstances:

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.

Comment 1

[Conrad Carlen (not reading bugmail)]

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

[bobj]

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

[Katsuhiko Momoi]

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

[Katsuhiko Momoi]

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

[Linda Baliman]

Adding lbaliman to cc-list;  nominating nsbeta1, nsbranch

Other people are also experiencing missing pieces of UI in Edit/Preferences

Comment 6

[bobj]

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

[Linda Baliman]

Adding nscatfood keyword (press feedback bug)

Comment 8

[Grace Bush]

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

[Jaime Rodriguez, Jr.]

Bhuvan - Any action on this?

Comment 10

[Grace Bush]

Attachment: diff of 6.0/6.1 profile directory- jpeg of diffs(p1)

Comment 11

[Grace Bush]

Attachment: profile diffs (2nd half) 6.0/6.1profile

Comment 12

[bobj]

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

Comment 13

[Grace Bush]

Attachment: user-locale.rdf 6.0 profile

Comment 14

[Grace Bush]

Attachment: user-skins.rdf file for 6.0 profile

Comment 15

[Grace Bush]

Attachment: user-locales.rdf file for 6.1 profile

Comment 16

[Grace Bush]

Attachment: user-skins.rdf file for 6.1 profile

Comment 17

[bobj]

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"?>
! <RDF:RDF
!      xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <RDF:Description about="urn:mozilla:package:messenger">
!     <NS593:selectedSkin xmlns:NS593="http://www.mozilla.org/rdf/chrome#" 
resource="urn:mozilla:skin:modern/1.0:messenger"/>
!   </RDF:Description>
!   <RDF:Description about="urn:mozilla:package:aim">
!     <NS594:selectedSkin xmlns:NS594="http://www.mozilla.org/rdf/chrome#" 
resource="urn:mozilla:skin:modern/1.0:aim"/>
    </RDF:Description>
    <RDF:Description about="urn:mozilla:package:navigator">
!     <NS595:selectedSkin xmlns:NS595="http://www.mozilla.org/rdf/chrome#" 
resource="urn:mozilla:skin:modern/1.0:navigator"/>
    </RDF:Description>
  </RDF:RDF>
--- 1,13 ----
  <?xml version="1.0"?>
! <RDF:RDF xmlns:c="http://www.mozilla.org/rdf/chrome#"
!          xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <RDF:Description about="urn:mozilla:package:messenger">
!     <c:selectedSkin resource="urn:mozilla:skin:modern/1.0:messenger"/>
    </RDF:Description>
    <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"/>
    </RDF:Description>
  </RDF:RDF>

Comment 18

[bobj]

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>
!   <RDF:Description about="urn:mozilla:package:cookie">
!     <c:selectedLocale resource="urn:mozilla:locale:en-US:cookie"/>
    </RDF:Description>
    <RDF:Description about="urn:mozilla:package:messenger">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:messenger"/>
    </RDF:Description>
    <RDF:Description about="urn:mozilla:package:help">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:help"/>
    </RDF:Description>
    <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"/>
    </RDF:Description>
  </RDF:RDF>
--- 10,31 ----
    <RDF:Description about="urn:mozilla:package:wallet">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:wallet"/>
    </RDF:Description>
!   <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>
    <RDF:Description about="urn:mozilla:package:messenger">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:messenger"/>
    </RDF:Description>
+   <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>
    <RDF:Description about="urn:mozilla:package:net2phone">
      <c:selectedLocale resource="urn:mozilla:locale:en-US:net2phone"/>
    </RDF:Description>
  </RDF:RDF>

Comment 19

[racham]

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.

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

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

[msanz]

changing qa contact to jonrubin. jonathan, can you answer ben's questions?

Comment 22

[Jon Rubin]

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

[Jon Rubin]

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"
observes="Browser:AddBookmarkAs"/>

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

[bobj]

cc jbetak

Comment 25

[Jon Rubin]

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

[Jon Rubin]

Attachment: Missing File menu items

Comment 27

[Jon Rubin]

Attachment: Personal Toolbar Folder missing

Comment 28

[bobj]

Jon,
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.

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

Comment 29

[bobj]

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

[Cindy Roberts]

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

[Jon Rubin]

Bob,

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

[bobj]

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

[bobj]

> 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

[David Hyatt]

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

[David Hyatt]

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

Comment 36

[bobj]

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="http://www.mozilla.org/rdf/chrome#"
!          xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
!   <RDF:Description about="urn:mozilla:package:cookie">
!     <c:selectedLocale resource="urn:mozilla:locale:ja-JP:cookie"/>
    </RDF:Description>
    <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>
    <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"/>
    </RDF:Description>
  </RDF:RDF>
--- 1,13 ----
  <?xml version="1.0"?>
! <RDF:RDF
!      xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
!   <RDF:Description about="urn:mozilla:package:net2phone">
!     <NS5:selectedLocale xmlns:NS5="http://www.mozilla.org/rdf/chrome#" 
resource="urn:mozilla:locale:ja-JP:net2phone"/>
    </RDF:Description>
    <RDF:Description about="urn:mozilla:package:messenger">
!     <NS6:selectedLocale xmlns:NS6="http://www.mozilla.org/rdf/chrome#" 
resource="urn:mozilla:locale:ja-JP:messenger"/>
    </RDF:Description>
    <RDF:Description about="urn:mozilla:package:aim">
!     <NS7:selectedLocale xmlns:NS7="http://www.mozilla.org/rdf/chrome#" 
resource="urn:mozilla:locale:ja-JP:aim"/>
    </RDF:Description>
  </RDF:RDF>

Comment 37

[Ben Goodger (use ben at mozilla dot org for email)]

This bug doesn't seem like a Navigator bug. 

Comment 38

[msanz]

adding PDT+, Tao will also work on it

Comment 39

[Frank Tang]

Tao, please take a look at this one.

Comment 40

[tao]

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,
too.

Hyatt?

Comment 41

[tao]

Attachment: ns6.01-ja/xyz/chrome/user-locales.rdf

Comment 42

[tao]

Attachment: The re-generated "ns6.01-ja/xyz/chrome/user-locales.rdf" by NS6.1b1

Comment 43

[Marek Z. Jeziorek]

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

[selmer (gone)]

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

Comment 45

[tao]

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

[saari (gone)]

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

Comment 47

[Viswanath Ramachandran]

There is still no patch to review, this bug is unfixed. Is there anyone other
than Hyatt who could fix this problem? 

Comment 48

[tao]

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. 

Comment 49

[[e-mail] (away - not reading bugmail)]

tao: have you tried to install and run different language packs? That triggered 
very similar problems during my tests for bug 86445.

Comment 50

[tao]

Yes, read my comments in 
--- Additional Comments From [e-mail] 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.

Comment 51

[Viswanath Ramachandran]

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

[tao]

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). 

Comment 53

[Viswanath Ramachandran]

*** Bug 84515 has been marked as a duplicate of this bug. ***

Comment 54

[tao]

Attachment: add localeVersion to packages and locale providers

Comment 55

[tao]

Attachment: add localeVersion to NS chrome providers

Comment 56

[tao]

Need r/sr for http://bugzilla.mozilla.org/showattachment.cgi?attach_id=41558 &
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=41559.

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?

Comment 57

[tao]

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
   1.1-1.3.
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

[David Hyatt]

sr=hyatt

Comment 59

[[e-mail] (away - not reading bugmail)]

r=jbetak

(I was just a little perplexed to find out, that the chrome registry part is 
already done - http://lxr.mozilla.org/seamonkey/search?string=localeVersion)

Comment 60

[David Hyatt]

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.  

Comment 61

[[e-mail] (away - not reading bugmail)]

Aha! Thanks for clarifying this...

Comment 62

[tao]

Thanks, folks, for the quick reviews. WIll check it in once the trunk open.

Comment 63

[tao]

Attachment: patch for security module.

Comment 64

[tao]

Patches (except secuirty module) checked into trunk. -> ddrinan

Comment 65

[tao]

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

[tao]

Attachment: patch for security module in branch.

Comment 67

[tao]

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. 

THX

Comment 68

[David P. Drinan]

Checked in the security patches into trunk and branch.

Comment 69

[Boris Zbarsky [:bzbarsky]]

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"
        chrome:author="mozilla.org"
        chrome:name="navigator-platform"
        chrome:localeVersion="0.9.3"/>
  </RDF:Description>

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

[tao]

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

[Jon Rubin]

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.

Comment 72

[Jon Rubin]

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

Comment 73

[Jon Rubin]

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

[jsnod]

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

[tao]

I am marking this as fixed since all problems appeared to be gone. Let's
address future findings in new bugs. Also --> tao.

Comment 76

[Jon Rubin]

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

[Jon Rubin]

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

Comment 78

[jsnod]

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

Comment 79

[timeless]

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

Comment 80

[Jon Rubin]

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

Comment 81

[tao]

*** Bug 91817 has been marked as a duplicate of this bug. ***