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

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

changing summary to reflect the need without specifying who has to do the work. assigning to sdagley to coordinate for M5, p2

tague informs me this has been pushed back to M6

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

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.

tague, are your recent Mac checkins enough to close this bug or does someting need to be done by the XPToolkit team?

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.

Ok, sliding to next milestone until we're ready to do something with this bug.

reassigning to me since this gets fixed with #6896.

Turned on fix today (6/13/99; 2:30pm). Should be in Monday's verification build.

tague, how can i verify this fix? (or could you please vouch that it is fixed?)

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.

cool... i hereby verify this bug as of the Jun 17 builds