[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093 Jianfeng Lin jianf...@microsoft.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jianfeng Lin jianf...@microsoft.com --- We agree with keeping the API simple and not adding isCandidateWindowVisible(). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093 Jianfeng Lin jianf...@microsoft.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jianf...@microsoft.com Resolution|FIXED |--- --- Comment #9 from Jianfeng Lin jianf...@microsoft.com --- How about the isCandidateWindowVisible() in the proposal https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html#widl-InputMethodContext-isCandidateWindowVisible-boolean It's equivalent to having a candidatewindowshow event fired without a matching oncandidatewindowhide event, but can be queried at any time, whereas the event approach requires the developer to listen to the events and update the status in a variable. When the page is going to show some UI, the developer could call this function to see if the candidate window is visible, and if so, call getCandidateWindowClientRect() and position the UI away from the candidate window. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093 Takayoshi Kochi ko...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Takayoshi Kochi ko...@google.com --- As getCandidateWindowClientRect()/oncandidatewindow* events added in the editor's draft, closing as resolved fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093 Travis Leithead [MSFT] tra...@microsoft.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX |--- --- Comment #5 from Travis Leithead [MSFT] tra...@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 on the CC list for the bug.
[Bug 22093] Consider adding candidatewindowshow/update/hide events and getCandidateWindowClientRect()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22093 Takayoshi Kochi ko...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Takayoshi Kochi ko...@google.com --- Although it looks convenient and nice to have these events, but in reality it would be very hard to implement this on non-windows and we have synchronousness issue (this is specific to Chrome though). Probably we have to explore alternative approach to this issue. -- You are receiving this mail because: You are on the CC list for the bug.
