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

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

--- Comment #1 from Takayoshi Kochi <kochi@google.com> ---
Our concerns:

* feasibility: are there non-Windows platforms that allow this to be
implemented?
* 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.
* synchronous: all the events are defined as synchronous but can this be a
problem
    if buggy usage of this events cause to lock the page or the user agent as a
    whole?  Can this be defined as asynchronous which can still allow lazy
    update of overlapping UI element to be moved?
* actual usage: if the candidate window size change, the suggest UI also change
    accordingly for each update?  It may be annoying UX, although we haven't
    really checked with demo implementation.
* 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?

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

Received on Monday, 20 May 2013 04:07:47 UTC