9926 - Need a reply mechanism for Ender's DOM event handlers

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[tague]

problem: to support input methods on some platforms (Macintosh, UNIX) we require
DOM event handlers to return information about the content and the result of
processing to the front end.  the current DOM event handlers only allow for a
binary reply - handled or not handled.  this isn't sufficent for my input method
code.

as an example, on the Macintosh there are three events Position2Offset,
Offset2Position and GetText which can't be supported by the current DOM event
handlers.  The Position2Offset needs a handler which can return an offset and a
region class (32-bit integer, enum) based on some computations done in Ender.
The Offset2Position event is similar.  The GetText event needs a reply which
contains a substing of a text node.

please let me know what I can do to help facilitate this work.

Comment 1

[bobj]

We cannot complete the IME feature implementation until we have this support.

Comment 2

[joki (gone)]

The current DOM event mechanism isn't likely to change however there are ways
within it that this functionality can be achieved.  The main one would be to
provide methods on the Event object for the information to be passed back.
This can be done fairly easily.  The hard part is the fact that currently all
added Event object methods are become visible to all DOM event handlers.  What
we'll need to support to do this right is the ability to create different types
of Event objects depending on the event.  I haven't yet added this capability
due to lack of need until this point.  Currently there is a base class
(nsIDOMEvent) and an inherited interface (nsIDOMUIEvent) but since the only
type of events we publicly support are UI events, we always create the second
type by default.

My suggestion would be to add the method to the current nsIDOMEvent but make it
clear though comments that they are methods of some new event object
(nsIDOMIMEEvent or somesuch).  When I add in the capability to create diffent
types of events I can move them.  While I wouldn't say I can't get to that by
M9 I'd say its unlikely unless my suggestion proves unworkable.

Comment 3

[tague]

changing assigned & QA contact

Comment 4

[tague]

should be in Friday Aug 6th verification builds (and later).

Teruko :-  a good way to test this would be to look at windows and see if the
candidate window is positioned near the IME input instead of the top left corner
of the screen.  positioning the candidate window uses this reply mechanism to
determine the coordinates to place the window

Comment 5

[Teruko Kobayashi]

I tested this in 8-11-09 Win32 and MAC.  This works fine in Windows, but this does not work in MAC.
Since this bug marks All platform, so I reopen this.

Comment 6

[tague]

The reply mechanism does work on Mac. It just has no visible manifestation.
There is already a bug (#4826) which captures the Mac candidate window
positioning.

This really shouldn't be reopened, but if QA would be more comfortable not
verifying it until #4286 is fixed that's ok.

Comment 7

[Teruko Kobayashi]

Verified.