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

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.

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

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.

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.

Adding lbaliman to cc-list; nominating nsbeta1, nsbranch Other people are also experiencing missing pieces of UI in Edit/Preferences

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.

Adding nscatfood keyword (press feedback bug)

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

Bhuvan - Any action on this?

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

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>

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>

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.

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

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

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

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.

cc jbetak

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

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?

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.

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.

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

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

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

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.

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

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>

This bug doesn't seem like a Navigator bug.

adding PDT+, Tao will also work on it

Tao, please take a look at this one.

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?

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.

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

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.

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

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

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.

Yes, read my comments in --- Additional Comments From tao@netscape.com 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.

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.

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

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

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?

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.

sr=hyatt

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)

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

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

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

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

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

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" 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>

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.

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.

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

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.

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?

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

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

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

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

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

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

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