Last Comment Bug 4819 - I18N needs Unicode input
: I18N needs Unicode input
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All Windows NT
: P2 normal (vote)
: M7
Assigned To: tague
: phillip
Mentors:
: 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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description 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 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 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 Steve Dagley 1999-04-26 13:51:59 PDT
tague informs me this has been pushed back to M6
Comment 4 Greg Kostello 1999-05-04 18:43:59 PDT
*** Bug 5928 has been marked as a duplicate of this bug. ***
Comment 5 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 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 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 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 tague 1999-06-11 19:38:59 PDT
reassigning to me since this gets fixed with #6896.
Comment 10 tague 1999-06-13 14:28:59 PDT
Turned on fix today (6/13/99; 2:30pm).  Should be in Monday's verification
build.
Comment 11 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 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 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.