[Webkit-unassigned] [Bug 13664] REGRESSION: Extra letter in Webkit/Spell Catcher Shorthand (abbreviation) expansion

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=13664





------- Comment #19 from evan at rainmakerinc.com  2007-06-30 23:41 PDT -------
(In reply to comment #18)
> Evan do you esxpect the space character to be inserted before or after your
> inputmethod logic occurs?
> 

This is what Spell Catcher does when expanding a shorthand abbreviation - as an
example say that typing "fyi" should result in "for your information":

1. In an application that does NOT support TSM document access and the required
sendRange parameter to the UpdateActiveInputArea event (the current state of
WebHTMLView, as it doesn't support the NSTextInputReplacementRangeAttributeName
attribute):

- user types f, then y, then i, then a whitespace or newline separator (we'll
say it's a space for illustrative purposes).

- Spell Catcher checks the "fyi" when it receives the space typed afterwards,
and finds the expansion "for your information".

- After determining it's an abbreviation that needs to be expanded, Spell
Catcher SUPPRESSES the space by returning to TSM that it has handled the event
in its entirety. THIS IS WHERE WebView is screwing up. No UpdateActiveInputArea
event has been sent (yet), the input method is simply returning a non-zero
ComponentResult from its Event dispatch call, which MUST be respected by the
application. Somehow the event is still getting through, even though TSM has
been told that it was handled, and therefore should NOT be handed off to the
client app.

- Spell Catcher calculates how many backspace characters need to be posted to
backspace over the "fyi" that was typed. REMEMBER, since the space character
has been suppressed (normally, in a properly functioning app) only 3 backspaces
need to be posted. Backspace and other control characters are handled very
differently in Cocoa apps vs. (most) Carbon apps if sent via an UAIA call. We
don't want ASCII 8 inserted into the document's text (tab characters pose a
particular problem here, but I digress). so we post them with the CGRemote
APIs. They need to be handled by the app as physical keystrokes.
=====THIS IS WHY the first letter of the abbreviation is "left behind" - take a
look at the original problem reports=====

- NOW, in an app that supports inline input via UpdateActiveInputArea (WebView
does at least support this), the expansion "for your information " is sent to
the application via an UpdateActiveInputArea call, specifying that all the text
should be dumped immediately - no inline area (marked text) should result. This
a prime example of text coming from an input method, and there is NO marked
text in the document before or afterward.
+++ ALSO NOTE CAREFULLY that the suppressed space following the f y i that was
typed, is appended to the expansion - there are a number of important reasons
it's done this way, no need to get into that aspect now, though.

So the basic problem stems from the fact that "input method-handled" events are
still getting through to and processed by WebView. If an input method wants an
event suppressed, the app must obey or really nothing is going to work properly
from that point on. This is the basis of many Spell Catcher features -
preventing double spaces, turning straight quotes into curly quotes, automatic
capitalization changes (in certain circumstances). This is all broken because
of this bug, and it's something that can absolutely not be worked-around at the
input method level.

The TSM Doc Access-aware situation is far more optimal, as Spell Catcher can
avoid backspacing entirely. It just replaces the "fyi " directly in the text
with "for your information ". No fuss, no muss, instantaneous. That's why
NSTextInputReplacementRangeAttributeName should be supported, but supporting it
has absolutely no relevance or relation to fixing this particular problem. I
don't think this bug and Bug 4681 are really duplicates. But they are in the
same very basic text input handling arena, and both need to be fixed. Fix this
one first, then optimize by supporting
NSTextInputReplacementRangeAttributeName. Supporting
NSTextInputReplacementRangeAttributeName without fixing this may get Spell
Catcher to work right, but other input methods that don't look for doc access
support in order to perform better will still have this
not-suppressing-the-character-I-told-you-to-suppress issues.

Phew!


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.