Input methods that do not maintain an active inline input area still need to know when the selection has changed. Generally this is determined by such an input method when it receives the kCMFixTextService component call. This call is made to TSM via -[NSInputManager markedTextAbandoned:]. Right now, _updateSelectionForInputManager test whether there is marked text, and returns immediately if that's the case: - (void)_updateSelectionForInputManager { if (![self hasMarkedText] || _private->ignoreMarkedTextSelectionChange) return; ... This is incorrect. The above needs to be changed to eliminate the hasMarkedText test, and continue on to do the "right thing" depending on whether the selection is inside the marked text or not. So the above needs to be changed to: - (void)_updateSelectionForInputManager { if (_private->ignoreMarkedTextSelectionChange) return; and then the "right thing" will be done for the case when an input method doesn't maintain an active inline input area.
Evan, could you please point to some documentation specifying this behavior? The documentation at <http://developer.apple.com/documentation/Carbon/Reference/Text_Services_Manager/tsm_refchap/ chapter_1.2_section_6.html> doesn't suggest such usage... My own input method works with inline input, so I haven't researched this myself a lot.
(In reply to comment #1) > Evan, could you please point to some documentation specifying this behavior? The documentation at > <http://developer.apple.com/documentation/Carbon/Reference/Text_Services_Manager/ tsm_refchap/ > chapter_1.2_section_6.html> doesn't suggest such usage... > > My own input method works with inline input, so I haven't researched this myself a lot. There's no actual documentation for this, probably because until my input method came along, there wasn't one that didn't maintain an inline input area AND needed to know when the selection in the document changed. The better solution might be to make sure that mouse events in WebView get passed along to the active input method. This is what happens in NSTextView. Problem is, I have no idea how this is or should actually be done. I think it may be happening (in NSTextView's case) somewhere other than the NSTextInput protocol methods or even mouseDown. Probably at some lower level mortals can't "get at". So the solution I propose here is one that's both do-able, works, and really shouldn't have any side- effects on input methods that do inline input as well (a call to fix should just be ignored by such an input method when there's no inline input happening, anyway).
I agree, making it pass mouse events to input methods sounds like a much better solution. Here is how it happens in NSTextView: #6 0x933adbd0 in TSMEventToTextService () #7 0x933adb44 in TSMEventToInputMethod () #8 0x933b4294 in TSMProcessMouseEvent () #9 0x9399a790 in -[NSTSMInputContext handleMouseEvent:] () #10 0x93758eb4 in -[NSTextView mouseDown:] () #11 0x9368d9c8 in -[NSWindow sendEvent:] () #12 0x93636bfc in -[NSApplication sendEvent:] () #13 0x9362e090 in -[NSApplication run] () #14 0x9371e8bc in NSApplicationMain ()
(In reply to comment #3) > I agree, making it pass mouse events to input methods sounds like a much better solution. Here is how > it happens in NSTextView: > > #6 0x933adbd0 in TSMEventToTextService () > #7 0x933adb44 in TSMEventToInputMethod () > #8 0x933b4294 in TSMProcessMouseEvent () > #9 0x9399a790 in -[NSTSMInputContext handleMouseEvent:] () > #10 0x93758eb4 in -[NSTextView mouseDown:] () > #11 0x9368d9c8 in -[NSWindow sendEvent:] () > #12 0x93636bfc in -[NSApplication sendEvent:] () > #13 0x9362e090 in -[NSApplication run] () > #14 0x9371e8bc in NSApplicationMain () > Sure, that's how it's done in NSTextView, but I see no way to do the same for WebView (well, unless you work at Apple). NSTSMInputContext isn't public (as you well know), and I have no idea if it's ok to call - [NSTSMInputContext handleMouseEvent:] from within -[WebHTMLView mouseDown:]. So yes, -[WebHTMLView mouseDown:] is obviously not finished (there's that TEXTINPUT comment, but no corresponding code!), and needs to be, but how? If you have any ideas, fire away...
Please see my comment in bug 4394. My understanding is that if we get that bug fixed, this one becomes INVALID, right?
(In reply to comment #5) Theoretically, YES, fixing 4394 should take care of this issue (as well as others). So now to figure out how to implement -[WebHTMLView(WebNSTextInputSupport) characterIndexForPoint:]. I really think it needs to be done, as it's probably needed elsewhere as well (PosToOffset??).
Seems a non-issue now that #4394 is fixed. At least not for my input method. I think we can pretty safely mark it as invalid.