[PP]Mac menus DON'T display Unicode correctly

VERIFIED FIXED in M7

Status

SeaMonkey
UI Design
P2
critical
VERIFIED FIXED
19 years ago
13 years ago

People

(Reporter: Fergus Sullivan, Assigned: tague)

Tracking

Trunk
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: QA BLOCKER - fix enclosed as patch; waiting for module owner to approve, URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Component: XP Miscellany → XPApps
(Reporter)

Comment 1

19 years ago
Changing component to XPApps.
(Reporter)

Updated

19 years ago
Assignee: brendan → trudelle
Priority: P3 → P2
QA Contact: 1680 → 4150
(Reporter)

Comment 2

19 years ago
And assigning to Peter Trudelle.  CC-ing L10n & I18n people.  Changing to P2
also.  Maybe it should be higher.
(Reporter)

Updated

19 years ago
Target Milestone: M5
(Reporter)

Comment 3

19 years ago
Setting TFV to M5.  You'd think I'd make all these changes in one go, wouldn't
you?

Updated

19 years ago
Priority: P2 → P3
Target Milestone: M5

Comment 4

19 years ago
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?

Updated

19 years ago
Assignee: trudelle → fergus

Comment 5

19 years ago
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.

Updated

19 years ago
QA Contact: 4150 → 4838
(Reporter)

Updated

19 years ago
Assignee: fergus → trudelle
Severity: critical → major
(Reporter)

Comment 6

19 years ago
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

19 years ago
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

Updated

19 years ago
Assignee: trudelle → saari
Priority: P3 → P2
Target Milestone: M5

Comment 8

19 years ago
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

19 years ago
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

19 years ago
So how do I test this, being that I don't run an internationalized OS version?
(Reporter)

Comment 11

19 years ago
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.

Updated

19 years ago

Comment 12

19 years ago
saari, you can find the Japanese XUL file at the URL mentioned above.

Updated

19 years ago
Whiteboard: QA BLOCKER

Comment 13

19 years ago
Adding to QA Blocker radar.

Updated

19 years ago
Whiteboard: QA BLOCKER → QA BLOCKER - need status update

Updated

19 years ago
Whiteboard: QA BLOCKER - need status update → QA BLOCKER - no fix in hand - might take on branch if one appears

Comment 14

19 years ago
and we get fergus over to saari's cube to help on this one?

Comment 15

19 years ago
I can definitely use some help. Everything I've tried so far hasn't had any
affect.
(Reporter)

Comment 16

19 years ago
On my way to talk to Saari now.

Comment 17

19 years ago
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?
(Assignee)

Comment 18

19 years ago
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.

Updated

19 years ago
Severity: major → blocker
(Assignee)

Comment 19

19 years ago
Update: i have this partially working - there is still a problem with
hierarchical menus and Unicode.  More later.

Comment 20

19 years ago
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?
(Assignee)

Comment 21

19 years ago
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

19 years ago
Ok, well one change I may check in is setting the menu item text with
SetMenuItemText(). That may help you.

Comment 23

19 years ago
Also, Mac menus arn't dynamic yet, so there will be more substantial changes to
them in the future.

Updated

19 years ago
Severity: blocker → critical

Comment 24

19 years ago
is there enough work done to remove the block status?  doing that now.
if this is wrong remark it blocker..
(Assignee)

Comment 25

19 years ago
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.

Updated

19 years ago
Target Milestone: M6 → M7

Comment 26

19 years ago
moving to M7

Updated

19 years ago
Blocks: 7228

Comment 27

19 years ago
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,
please?

Comment 28

19 years ago
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

19 years ago
Tague and Frank, please comment on whether we should use Mozilla's converters
or Mac converters (from Unicode to system script).
(Assignee)

Comment 30

19 years ago
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
converters.

Comment 31

19 years ago
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

19 years ago
Ok, what API should I be looking at? (sorry, not up to speed on TSM)
(Assignee)

Comment 33

19 years ago
Created attachment 309 [details] [diff] [review]
bug fix patch
(Assignee)

Updated

19 years ago
Whiteboard: QA BLOCKER - no fix in hand - might take on branch if one appears → QA BLOCKER - fix enclosed as patch; waiting for module owner to approve
(Assignee)

Comment 34

19 years ago
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.

Updated

19 years ago
Summary: Mac menus DON'T display Unicode correctly → [PP]Mac menus DON'T display Unicode correctly
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 35

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → REOPENED

Updated

19 years ago
Assignee: saari → tague
Status: REOPENED → NEW

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago

Comment 36

19 years ago
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. :-}
(Reporter)

Updated

18 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 37

18 years ago
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

18 years ago
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?
(Reporter)

Comment 39

18 years ago
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.
(Assignee)

Comment 40

18 years ago
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

18 years ago
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.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.