[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093

Masayuki Nakano <masayuki@d-toybox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |masayuki@d-toybox.com

--- Comment #2 from Masayuki Nakano <masayuki@d-toybox.com> ---
(In reply to comment #1)
> * feasibility: are there non-Windows platforms that allow this to be
> implemented?

I think that it's "no". AFAIK, we cannot implement these features on Mac and
Linux.

On Linux (GTK), applications can just set the position of caret.
https://developer.gnome.org/gtk3/unstable/GtkIMContext.html#gtk-im-context-set-cursor-location
Please note that this does NOT specify the candidate window position. IME can
just refer this information at deciding the position.

On Mac, applications just return the queries from other applications (including
IME). Typically, IME may refer the position of one character of the composition
string.
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/NSTextInputClient_Protocol/Reference/Reference.html
NSTextInputClient's firstRectForCharacterRange:actualRange: can be available
for getting ANY character position of the composition string.

Therefore, I don't think that the candidate window related APIs are realistic
plan.

> * event target: why isn't input DOM element the target of this event?
>     The proposal says it is for performance, but what if lots of input
> elements
>     exist in a page all wanting to listen to the events?  It would be nice
>     if developer only register one listener on <body> and can be able to
>     get all the events.

I agree with that. I feel that the Microsoft's proposal is a little bit complex
for implementing the event model. I believe that nobody wants to implement new
DOM event mechanism. According to the proposal, we need to do it.

The proposal says that InputMethodContext instance is created for each element
even if the element is NOT editable. This means that when web browser fires the
proposed events, it needs to find the all InputMethodContext instances which
belong to the focused editing host.

And I believe that InputMethodContext should belong to <input>, <textarea> or
editing host of contenteditable or designMode. Then, browsers need to
create/store the InputMethodContext instance per the editor. It's easier to
manage the instance than the proposal spec.

> * clarification: on mobile platforms, showing candidate window can be
> transparent
>     to the running application and getting CandidateClientRect() may make no
>     sense (or just impossible).  On such a platforms, these events could just
>     be ignored to implement?

I think so. Even if the candidate window related APIs are espoused, they should
be for "floating" candidate window on window based GUI environment. Anyway,
both UI -- IME native candidate list and Web app specific suggesting list --
are not useable in narrow display of mobile device.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 20 May 2013 11:11:44 UTC