Bug 16046 – WebHTMLView returns noErr for kTSMDocumentSupportDocumentAccessPropertyTag in non-editable areas

• Status: UNCONFIRMED
• Component: HTML Editing

[Evan Gross]

When an input method tries to determine whether a TSMDocumentID supports TSM's DocumentAccess event suite, it calls TSMGetDocumentProperty with the kTSMDocumentSupportDocumentAccessPropertyTag. The result from WebHTMLView indicates docaccess support even if its non-editable!

This gets input methods very confused, especially given that no error is returned from SendTextInputEvent for kEventClassTSMDocumentAccess events kEventTSMDocumentAccessGetLength and kEventTSMDocumentAccessGetSelectedRange.

To make matters even worse, the event parameters contain "interesting" values. For kEventTSMDocumentAccessGetLength, on 10.4.11 it appears that an actual length is returned. On 10.5.1, zero is returned. For kEventTSMDocumentAccessGetSelectedRange, kEventParamTSMDocAccessReplyCharacterRange contains NSMakeRange(NSNotFound, 0). This is especially bad, since that parameter is supposed to be of type typeCFRange. But NSNotFound has no special meaning here as CFRange's location is a signed type, and NSNotFound != kCFNotFound. Without special consideration, this would be interpreted by the input method as an insertion point at offset 2147483648. Not a good thing. My input method doesn't crash because of this, but I can image that it could lead to one.

I don't have a machine with a system older than 10.4.11 installed on it, but I am quite certain this is a  regression.

I'm not sure how the kTSMDocumentSupportDocumentAccessPropertyTag is actually derived by TSM, if it's done via validAttributesForMarkedText should it actually return an empty array or nil.

[Evan Gross]

Filed as <rdar://problem/5607681> because of its nastiness, and that a fix really needs to make it into a system update.

[Alexey Proskuryakov]

I have a machine with 10.4.10 - can you suggest a quick way to verify this?

Also, you can enable logging in a debug build of WebKit to see what input-related methods get called:

defaults write com.apple.Safari WebKitLogLevel 10

[Evan Gross]

(In reply to comment #2)
> I have a machine with 10.4.10 - can you suggest a quick way to verify this?
> 

If you enable the developer features in the shipping version of Spell Catcher X (10.2.3) with:

defaults write com.rainmaker.SpellCatcher SCEnableTSMTestsMenu -bool TRUE

And select the TSM Tests > Document Access item, it can tell you some of what's going on (there's a little debug logging in the release version when that default is set, but it's not necessarily that informative).

OK, I have a machine with Mac OS X Server 10.4.10 installed on one of its partitions, and did a bit of testing. It looks like this may not be a *total* regression, as WebHTMLView on 10.4.10 also reports that it supports TSM DocAccess for non-editable areas (which of course, is wrong). HOWEVER, it actually behaves a LOT better, as the results from a number of docaccess events seem to be correct (kEventTSMDocumentAccessGetLength, kEventTSMDocumentAccessGetSelectedRange, kEventTSMDocumentAccessGetCharacters look OK, however kEventTSMDocumentAccessGetFont looks wrong and of course, kEventTextInputUpdateActiveInputArea isn't going to do anything with or without kEventParamTextInputSendReplaceRange).

The fact that this item is enabled means that the active TSMDocumentID claims to support docaccess. In the palette window, you can see the docaccess values for length and selected range. You won't see any highlighted errors in non-editable areas (because kEventTSMDocumentAccessGetFont returns bogus values, at least for effectiveRange), but in editable areas that support docaccess tooltips for highlighted words contain quite a bit of useful info.

As well, Spell Catcher uses docaccess (if available) to determine the currently-selected text, and shows it in those menu items that operate on it (Check Word, Look Up, Find in References). On 10.4.10, the selected word appears, therefore docaccess is "supported" and supplying the selected text properly. If docaccess is not supported, it tries kEventClassTextInput / kEventTextInputGetSelectedText, and if it gets an error, falls back to displaying "Check Word", "Look Up" etc. On 10.4.11/10.5.x, docaccess is "supported", but returns empty/nil/bogus values for the various docaccess events, so you don't see the selected word in those menu commands (kEventTSMDocumentAccessGetSelectedRange returns a zero-length range, Spell Catcher concludes there is no selection). This turns out to be a problem, as those command no longer work properly - primarily because it "believes" what the app is returning from these APIs. Doc Access is supported, the selected range is empty, therefore there is no need to perform any sort of "clipboard charade" to obtain the selected text. Commands no longer work, customers get confused and/or pissed, and so it goes...

(This feature is going to be "real" in the upgrade I'm working on, I can certainly make it available to you, as it has a superior implementation.)

> Also, you can enable logging in a debug build of WebKit to see what
> input-related methods get called:
> 
> defaults write com.apple.Safari WebKitLogLevel 10
> 

This wasn't very informative on 10.5.1, as Spell Catcher doesn't get very far or do a whole lot because the value returned for the document's length is zero. It pretty much bails at that point. The (NSNotFound, 0) thing for the selected range puts a stop to things as well.

All that said, there appears to be an even more serious problem on 10.4.11/10.5.x that for certain isn't the case on 10.4.10. I haven't written that one up yet (maybe tomorrow), but it does relate to this bug. The basic issue is that the same TSMDocumentID is used for both non-editable and editable areas, which is causing me massive grief and may cause other input methods some definite trouble as well. There is absolutely zero indication given to an input method when you (say) use the tab key to move the focus from the (non-editable) page that's landed on to (say) an input area. No activate/deactivate, no fix, nothing. I can't find a reliable work-around that doesn't involve some sort of polling for either problem. Truly nasty.