This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Add candidatewindow{show,update,hide} events on InputMethodContext as described in https://dvcs.w3.org/hg/ime-api/raw-file/tip/proposals/IMEProposal.html as well as getCandidateWindowClientRect() for the API to be useful. interface InputMethodContext : EventTarget { ...snip... ClientRect getCandidateWindowClientRect (); attribute EventHandler oncandidatewindowshow; attribute EventHandler oncandidatewindowupdate; attribute EventHandler oncandidatewindowhide; }; The use case is to align/position search suggest UI dropdown when candidate window UI appears.
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?
(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.
Event target: is there any scenario where the developer wants to listen to candidatewindowshow of all the input boxes on the same page and run them through the same event handler? Our thinking is no, because the developer wants to position the suggestion list of a specific input box relative to that input box and its candidate window. The event handler would be different for each input box that needs this, and not all of the input boxes will need this. Not sending the event to input boxes that don’t have input method context and avoiding the event bubbling could save performance here. Synchronous: this has to be synchronous to avoid overlapping of IME and any other UI provided by the web app. Overlapping for an undetermined short time and then separating them is not a polished user experience. Actual usage: yes the suggestion UI could change with to keep consistent with the width of the IME candidate window, although a better design is that the IME candidate window maintains a fixed width that is the same as the input box, left aligns to the input box and docks below it. This is what we expect from specifying ime-align:after. Clarification: for mobile platforms where the IME UI is part of the keyboard, yes this event could be ignored and not be fired. It’s still useful for developers to get compositionText to assist dynamic search suggestions, but as the occlusion issue is not there, it’s unnecessary to tell developers where inside the keyboard is the IME. Maybe isCandidateWindowVisible() could return false, as technically it’s not a window, it’s part of the keyboard and developers shouldn’t worry about its existence. They could use hasComposition() and compositionstart event to find out that IME composition is going on.
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.
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 :-)
After some investigation, I come to know that events that fire against non-DOM elements are okay, like XMLHTTPRequest's onreadystatechange. Though still we have uncertainty for implementing this on non-Windows platforms, we intend to include this in the spec and test it on Windows platform to see how useful it would be. This API and events are probably useful for showing suggests from web or local IME candidates exclusively. For mobiles, the scenario would be different. Maybe window resize can be one possibility for that, but it may not be just for showing on-screen keyboards.
Added events and getCandidateWindowClientRect() at https://dvcs.w3.org/hg/ime-api/rev/10a3d6ec9336
As getCandidateWindowClientRect()/oncandidatewindow* events added in the editor's draft, closing as resolved fixed.
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.
Technically adding isCandidateWindowVisible() sounds easy, once candidatewindowshow/hide is implemented, it just returns cached state. Basically I want the spec to be as minimal as possible to provide bare minimum, so this convenient function is not necessarily mandatory, and I am also wondering the usefulness of the return value of this function, as usually a candidate window is a short-lived UI which disappears once the user finishes choosing a candidate. If the method returns true, the candidate may close immediately after that, or if it returns false, a new candidate window may appear soon after that. So showing a UI (such as search suggestions) which may outlive the candidate window on a location that avoids soon-disappearing window may give weird impression on users. Do you have a viable demo that uses this function and saves lots of code compared to using oncandidatewindow* events, and still useful to construct a usable UI? I'm not completely convinced for the reasons above.
We agree with keeping the API simple and not adding isCandidateWindowVisible().