Bug 4699 – _updateSelectionForInputManager MUST ensure that input methods receive kCMFixTextService even if no marked text

• Status: RESOLVED
• Resolution: INVALID
• Component: HTML Editing

[Evan Gross]

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.

[Alexey Proskuryakov]

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.

[Evan Gross]

(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).

[Alexey Proskuryakov]

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 ()

[Evan Gross]

(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...

[Alexey Proskuryakov]

Please see my comment in bug 4394.

My understanding is that if we get that bug fixed, this one becomes INVALID, right?

[Evan Gross]

(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??).

[Evan Gross]

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.