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

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

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #5 from Travis Leithead [MSFT] <travil@microsoft.com> ---
I’m not sure I understand the synchronousness issue, but given other APIs in
the web platform have this synchronous behavior, this is something that can be
worked around in Chrome I believe.

Honestly, I doubt there is a way to solve the problem using the union of the
IME APIs available for Windows/Mac/Linux, and someone is going to have to push
the platforms forward in this respect. Either they add support to the platform
for (1) the IME to tell the app where it’s window is located and when it’s
appearing [our proposal], (2) the app declares to the IME where it wants the
candidate window to appear and at what size, or (3) a more complex UILess-mode
style API where the browser renders the candidate list on behalf of the IME. #2
and #3 are much more ripe for abuse.

Additional note: Windows Cicero API now basically have support for #1 and #3;
we used to have a limited form of #2 (couldn’t get specific size), but that’s
only in the deprecated IMM32 API, which we are not comfortable building on, and
which may or may not work going forward.

>> Probably we have to explore alternative approach to this issue.

Yep, and for that reason, I reactivated the bug :-)

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

Received on Tuesday, 20 August 2013 18:27:36 UTC