Last Comment Bug 4819 - I18N needs Unicode input
: I18N needs Unicode input
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All Windows NT
P2 normal (vote)
: M7
Assigned To: tague
: phillip
: Neil Deakin
: 5928 (view as bug list)
Depends on:
Blocks: 7228 7577
  Show dependency treegraph
Reported: 1999-04-08 18:03 PDT by tague
Modified: 1999-06-17 17:18 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image tague 1999-04-08 18:03:50 PDT
The input path for Seamonkey needs to be Unicode Internally.  We need the
XPWidget/XPToolkit code to map between native platform events and Unicode for
keyboard input.

The International group will be providing an adapter layer to map between the
native platform character set and unicode.  We need the XPWidget/XPToolkit
group to adopt this adapter layer and ensure that their code is Unicode clean.
We also need the XPWidget/XPToolkit group to pass Unicode data to the core
DOM/layout layers of the event path.

See related bug #4816, #4817
Comment 1 User image Steve Dagley 1999-04-08 18:44:59 PDT
Adding joki and kostello to the cc: list.  This is more far reaching than just
XPToolkit as it encompases core Gecko and editor issues (the internal event model
is owned by Gecko, not XPToolkit for example).
Comment 2 User image Peter Trudelle 1999-04-10 11:53:59 PDT
changing summary to reflect the need without specifying who has to do the
work. assigning to sdagley to coordinate for M5, p2
Comment 3 User image Steve Dagley 1999-04-26 13:51:59 PDT
tague informs me this has been pushed back to M6
Comment 4 User image Greg Kostello 1999-05-04 18:43:59 PDT
*** Bug 5928 has been marked as a duplicate of this bug. ***
Comment 5 User image Steve Dagley 1999-05-14 19:54:59 PDT
Still expecting to have to do _something_ for I18N but haven't heard anything
about it in M6 so moving to M7 to keep on the radar.
Comment 6 User image Steve Dagley 1999-06-06 15:21:59 PDT
tague, are your recent Mac checkins enough to close this bug or does someting
need to be done by the XPToolkit team?
Comment 7 User image tague 1999-06-07 16:43:59 PDT
the recent Mac changes were unrelated to this bug.
i'll let you know when we need additional work from XPToolkit, right now this
conversion can really be done until other problems are taken care of.
Comment 8 User image Steve Dagley 1999-06-07 17:20:59 PDT
Ok, sliding to next milestone until we're ready to do something with this bug.
Comment 9 User image tague 1999-06-11 19:38:59 PDT
reassigning to me since this gets fixed with #6896.
Comment 10 User image tague 1999-06-13 14:28:59 PDT
Turned on fix today (6/13/99; 2:30pm).  Should be in Monday's verification
Comment 11 User image phillip 1999-06-17 16:37:59 PDT
tague, how can i verify this fix? (or could you please vouch that it is fixed?)
Comment 12 User image tague 1999-06-17 17:09:59 PDT
you can probably just mark the bug verified. it really is more of a code thing
than a functional thing.

if you want to check it, you can just make sure that high ascii and non-roman
characters (like german or japanese) display in the editor window.  usually if a
platform isn't doing unicode input it has blobs or squares.
Comment 13 User image phillip 1999-06-17 17:18:59 PDT
cool... i hereby verify this bug as of the Jun 17 builds

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