Last Comment Bug 5402 - [PP]Mac menus DON'T display Unicode correctly
: [PP]Mac menus DON'T display Unicode correctly
QA BLOCKER - fix enclosed as patch; w...
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: PowerPC Mac System 8.5
P2 critical (vote)
: M7
Assigned To: tague
: Fergus Sullivan
Depends on:
Blocks: 7228
  Show dependency treegraph
Reported: 1999-04-22 15:21 PDT by Fergus Sullivan
Modified: 2004-11-23 18:54 PST (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

bug fix patch (12.75 KB, patch)
1999-06-01 20:20 PDT, tague
no flags Details | Diff | Splinter Review

Description User image Fergus Sullivan 1999-04-22 15:21:26 PDT
Take navigator.xul and change a couple of strings to Japanese or to European
extended characters (using Unicode).  On Win, all on-screen widgets look good,
on Mac, the menus and any HTML buttons or Menu popups are corrupted.

It looks like MacFE still expects either Shift-JIS or MacRoman, as appropriate.
It should be looking for and displaying Unicode characters.

Logging as XP Misc, although maybe it should be XUL.
Comment 1 User image Fergus Sullivan 1999-04-22 15:26:59 PDT
Changing component to XPApps.
Comment 2 User image Fergus Sullivan 1999-04-22 15:28:59 PDT
And assigning to Peter Trudelle.  CC-ing L10n & I18n people.  Changing to P2
also.  Maybe it should be higher.
Comment 3 User image Fergus Sullivan 1999-04-22 15:36:59 PDT
Setting TFV to M5.  You'd think I'd make all these changes in one go, wouldn't
Comment 4 User image Peter Trudelle 1999-04-22 17:44:59 PDT
Clearing target milestone and resetting priority to p3. These fields are owned by
engineering, please do not touch them. Also, this should have been filed as three
separate bugs, one for each widget, not lumping everything together.  Could you
split it up?
Comment 5 User image Peter Trudelle 1999-04-23 13:51:59 PDT
also, the severity of this bug is not critical, which is defined as "crashes,
loss of data, severe memory leak". Reassigning to fergus to split up and refile
with appropriate severities.
Comment 6 User image Fergus Sullivan 1999-04-23 14:58:59 PDT
Okay.  Changing to severity to major.  And calling this one the Menu bug.
Others will follow for popup html menus and for html buttons.

Also assigning back to trudelle as split is done.
Comment 7 User image msanz 1999-04-23 15:30:59 PDT
Peter, Fergus is also an engineer. Priority is high because we cannot pseudo
localize the product if this does not work correctly, and we have a pseudo
localization task for M5 (inherited from M4) that is blocked by this now.
Please, reset this bug, 5438 and 5439 accordingly
Comment 8 User image Peter Trudelle 1999-04-23 15:42:59 PDT
Okay, but we may not get to these for M5.  Chofmann has dictated that we reduce
our individual bug lists to the top 2 bugs as of next Tuesday.  In general,
bugs that affect everyone will be triaged with higher priority than those that
just affect I18N.
reassigning to saari as p2 for m5
Comment 9 User image Peter Trudelle 1999-04-23 15:59:59 PDT
Also, when I said 'engineering, I meant only the development team responsible
for fixing the bug. QA professionals are also engineers, but they own the
severities, not the priorities.
Comment 10 User image saari (gone) 1999-04-27 17:44:59 PDT
So how do I test this, being that I don't run an internationalized OS version?
Comment 11 User image Fergus Sullivan 1999-04-27 18:19:59 PDT
Saari, try using generic extended characters.  é and such like.  Be aware,
though, that they need to be entered as UTF8 into the navigator.xul file.

Here's how to produce a UTF8 character on any Mac.  Open a new Doc in composer.
Select View>Character Set>UTF-8

Type some extended characters--try using option-a for a 'å'.  Save HTML.  copy
the strings concerned and their encoding into navigator.xul and watch behaviour.

Note that many widgets work.  Menus is one that doesn't.
Comment 12 User image msanz 1999-04-27 19:05:59 PDT
saari, you can find the Japanese XUL file at the URL mentioned above.
Comment 13 User image leger 1999-04-28 16:26:59 PDT
Adding to QA Blocker radar.
Comment 14 User image chris hofmann 1999-05-03 16:38:59 PDT
and we get fergus over to saari's cube to help on this one?
Comment 15 User image saari (gone) 1999-05-03 17:17:59 PDT
I can definitely use some help. Everything I've tried so far hasn't had any
Comment 16 User image Fergus Sullivan 1999-05-03 17:20:59 PDT
On my way to talk to Saari now.
Comment 17 User image saari (gone) 1999-05-03 19:21:59 PDT
So if anyone has insight on how to fix this, I'd love to hear it...
SetMenuItemTextEncoding is new with Appearance, and takes a script ID, which I
don't have at runtime anyway.

What is the right magic to get the menu manager to do this correctly?
Comment 18 User image tague 1999-05-04 10:55:59 PDT
Chris :- If you point me at some code, I can take a look at this and see if we
can get things up and running correctly.
Comment 19 User image tague 1999-05-05 15:52:59 PDT
Update: i have this partially working - there is still a problem with
hierarchical menus and Unicode.  More later.
Comment 20 User image saari (gone) 1999-05-05 16:32:59 PDT
Anything I can help with? I can probably figure it out if I see the code that
does the right thing. In other words, is this checked in yet?
Comment 21 User image tague 1999-05-05 16:56:59 PDT
Nothing checked in yet.  I fixed the problem with hierarchicals, but I'm having

problems with Japanese in the file menu at the moment.  I'm going to send mail to

some ex-colleagues at Apple to get some more information.

There may need to be some re-thinking of the mac implementation of the menu code

- we can talk about that later, after I get information back from Apple.

I'll let you know if there is anything I need help with.
Comment 22 User image saari (gone) 1999-05-05 18:15:59 PDT
Ok, well one change I may check in is setting the menu item text with
SetMenuItemText(). That may help you.
Comment 23 User image saari (gone) 1999-05-05 18:45:59 PDT
Also, Mac menus arn't dynamic yet, so there will be more substantial changes to
them in the future.
Comment 24 User image chris hofmann 1999-05-10 12:02:59 PDT
is there enough work done to remove the block status?  doing that now.
if this is wrong remark it blocker..
Comment 25 User image tague 1999-05-10 12:19:59 PDT
I don't think this can be considered a QA blocker - I don't think it is going to
be technically possible to use Unicode in Mac Menu drawing.

I talked to some ex-coworkers at Apple about ATSUI, the new Menu Manager and
Unicode Menus.  According to them, the Menu Manager doesn't use ATSUI and
doesn't support Unicode drawing.  The support we will be able to do for Unicode
menus on the Mac is going to be limited.

The code needs to convert the Unicode data into the encoding of the system
Script; however, we won't be able to have Japanese menu's on a US system.  The
Unicode data will have to be limited to characters that can be displayed by the
system script.
Comment 26 User image saari (gone) 1999-05-17 12:17:59 PDT
moving to M7
Comment 27 User image Erik van der Poel 1999-05-27 11:40:59 PDT
Montse, when do you need to have this fixed?

Saari, do you have enough info now to fix it? I.e. convert from Unicode to
system script, and then pass to menu. If not, can you get the info from Tague,
Comment 28 User image saari (gone) 1999-05-27 12:30:59 PDT
I know we have calls to do this on Windows, how about Mac? Or should I be using
the OS stuff (is there a Unicode to Shift JIS converter in the OS now?)
Comment 29 User image Erik van der Poel 1999-05-27 13:10:59 PDT
Tague and Frank, please comment on whether we should use Mozilla's converters
or Mac converters (from Unicode to system script).
Comment 30 User image tague 1999-05-27 13:50:59 PDT
I think in cases like this, it makes much more sense for us to use the platform
encoding converters.  Both Frank and I are using the platform encoding
converters in platform specific parts of the code (Frank for ATSUI drawing, me
for key/IME input into Unicode strings).

For purely platform-specific parts of the code, it is much easier to use the
platform encoding converters (if they exist), because they have knowledge about
the kind of conversions that need to be done at that level (system encoding to
Unicode).  That knowledge isn't really built into the Mozilla encoding
Comment 31 User image Erik van der Poel 1999-05-27 15:07:59 PDT
OK, Saari, please use the Mac converter to convert from Unicode to the system
script. If you don't know how to do this, please contact tague or ftang.
Comment 32 User image saari (gone) 1999-05-27 15:20:59 PDT
Ok, what API should I be looking at? (sorry, not up to speed on TSM)
Comment 33 User image tague 1999-06-01 20:20:59 PDT
Created attachment 309 [details] [diff] [review]
bug fix patch
Comment 34 User image tague 1999-06-01 20:21:59 PDT
I have a patch for this which I sent to various Mac people to look at and
approve.  I will check this in, once I get approval.
Comment 35 User image tague 1999-06-02 17:38:59 PDT
checked in a fix today, 6/2/98 - 5:30pm.

Note: we are only going to support drawing the menu bar (i.e. the menu label) in
the system script.  This means that you will only be able to display a Japanese
menu bar on a Japanese system.  The actual menu text will be multi-lingual.
Comment 36 User image bobj 1999-06-07 17:02:59 PDT
Temporarily reopened, so I can reassign to Tague.
I'm doing my anal-rententive management thing and trying to track what bugs
my group is fixing. :-}
Comment 37 User image Fergus Sullivan 1999-06-21 14:21:59 PDT
Verifyied against June 18 build.

Note that difference between native widgets and macos means that proper display
is only possible under KanjiTalk.  JLK isn't enough for once.
Comment 38 User image bobj 1999-06-22 10:58:59 PDT
What doesn't work on JLK.  Just the menu bar or also the menu entries?
We know the menu bar is not multilingual, but do multilingual menu entries
display on JLK?
Comment 39 User image Fergus Sullivan 1999-06-22 11:05:59 PDT
Just the menu bar.  If we go down the route of registering it as JA application
(using language register hooks) then this would be rectified.
Comment 40 User image tague 1999-06-22 12:50:59 PDT
the menu items are "mono"-multilingual.  any menu item can be displayed in any
macintosh script, but you can't mix two scripts in the same menu item.  you can
have Japanese, German, Indic, Chinese menu items in the same XUL file, and they
will be displayed fine, but you couldn't do something like Save as... where
"save" was in Japanese and "as" was in chinese.

The actual menu bar is special.  It will only draw in the system script, so you
can only support Japanese or Chinese in the menu bar.  This won't work with just
a language kit, unless as fergus mentions, the user uses the lanugage kit
registration application and registers the application as a japanese or a
chinese application.  whatever the application is registered as determines what
script can be displayed in the menu bar.

the only way around this limitation is to write a custom MDEF which does Unicode
drawing.  that would be incredibly painful and too time consuming.
Comment 41 User image bobj 1999-06-22 14:08:59 PDT
It's good to clarify what is implemented.  Thanks.

The current implementation supports 99.99% of the cases that matter.
The menu bar will normally be mono-lingual for the current localization.
When the Mac app is localized, we should set the language setting appropriately.
And it will be very rare that a single entry (e.g. What's Related, document
title, bookmark) will contain characters from more than one script.

I think there is no reason to do a custom MDEF.

Note You need to log in before you can comment on or make changes to this bug.