Bug 4699
Summary: | _updateSelectionForInputManager MUST ensure that input methods receive kCMFixTextService even if no marked text | ||
---|---|---|---|
Product: | WebKit | Reporter: | Evan Gross <evan> |
Component: | HTML Editing | Assignee: | Dave Hyatt <hyatt> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | ap |
Priority: | P2 | ||
Version: | 420+ | ||
Hardware: | Mac | ||
OS: | OS X 10.4 |
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.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
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.