I18N needs Unicode input

VERIFIED FIXED in M7

Status

()

Core
XUL
P2
normal
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: tague, Assigned: tague)

Tracking

Trunk
All
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

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

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

Updated

19 years ago
Priority: P3 → P2
Summary: Need XPToolkit/XPWidgets to provide Unicode input → I18N needs Unicode input
Target Milestone: M5

Comment 2

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

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Target Milestone: M5 → M6

Comment 3

19 years ago
tague informs me this has been pushed back to M6

Comment 4

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

Updated

19 years ago
Target Milestone: M6 → M7

Comment 5

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

Updated

19 years ago
Blocks: 7577

Comment 6

19 years ago
tague, are your recent Mac checkins enough to close this bug or does someting
need to be done by the XPToolkit team?
(Assignee)

Comment 7

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

Updated

19 years ago
Target Milestone: M7 → M8

Comment 8

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

Updated

19 years ago
Blocks: 7228
(Assignee)

Updated

19 years ago
Assignee: sdagley → tague
Status: ASSIGNED → NEW
Target Milestone: M8 → M7
(Assignee)

Comment 9

19 years ago
reassigning to me since this gets fixed with #6896.
(Assignee)

Comment 10

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

Comment 11

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

Comment 12

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

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 13

18 years ago
cool... i hereby verify this bug as of the Jun 17 builds
You need to log in before you can comment on or make changes to this bug.