[Webkit-unassigned] [Bug 16046] WebHTMLView returns noErr for kTSMDocumentSupportDocumentAccessPropertyTag in non-editable areas

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 20 01:03:36 PST 2007


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





------- Comment #3 from evan at rainmakerinc.com  2007-11-20 01:03 PDT -------
(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.


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



More information about the webkit-unassigned mailing list