Bug 70882 – WebView hangs if input method inserts text if Check Spelling While Typing is on

• Component: HTML Editing
• Status: UNCONFIRMED

[Evan Gross]

Created attachment 112469 [details]
Document for testing, Activity Monitor sample texts.

Summary:

On Snow Leopard and Lion, in an editable WebView, when Check Spelling While Typing is turned on, it's possible for a deadlock (hang) to occur if an input method application modifies the document's text after a space is typed.

Steps to Reproduce:

1. Download and install Spell Catcher X 10.4 from:
<http://www.rainmakerinc.com/dl/demos/SpellCatcherX.dmg>
2. Launch the Spell Catcher application, let it install both the input method component and input method application.
3. Make sure you test using the latest nightly build. Spell Catcher X 10.4 has a reasonably effective work around for this bug specifically for Safari. Since the Safari app in nightly builds have a different bundle identifier, this work around shouldn’t “kick in”.
4. Double click to open the enclosed "Test Shorthands.glossary" file.
5. Launch WebKit (nightly), make sure that Edit > Spelling and Grammar > Check Spelling While Typing is selected.
6. Navigate to any web page that has a textarea that can accept a few rows of text. The one on Radar, where I'm (initially) entered this report’s summary) will do.
7. Select Spell Catcher from the Input menu, make sure that the "Interactive Checking" command in Spell Catcher’s Input menu is selected.
8. Type one of the abbreviations for the shorthands in the "Test Shorthands" file, followed by a return character. Those with multi-line expansions are more likely to cause the problem to occur, but others can as well. So, try "mlines" or "addr" or "sigr". It may take a few tries to reproduce the problem, seems to be easier on slower Macs. Typing space instead of return as the separator/trigger can also repro the problem, but seems easier using return.
9. WebKit will hang - keep trying if it doesn't happen the first time.

Expected Results:

No hang!

Actual Results:

WebView will (often) deadlock shortly after the word separator is typed. See the enclosed Samples and hang reports. Seems that while WebKit is waiting on the result from NSSpellCheckerCheckString (-[NSSpellChecker _checkSpellingAndGrammarInString:range:enclosingRange:offset:types:options:orthography:inSpellDocumentWithTag:mutableResults:wordCount:]), it may then handle a -[IMKInputSession insertText:replacementRange:] request, which in turn triggers a call to NSSpellCheckerCheckString, causing the deadlock.

(The above applies to the original samples I submitted, check the ones enclosed with this report. I believe they are very similar, but maybe not exactly as described above).

I may not be entirely correct on this one, but it looks like some sort of DO-related issue.

Regression:

I first ran into this before the release of Snow Leopard while working on Spell Catcher’s input method application. I did find a reasonably effective work around for this problem for Mail and Safari, by adjusting the timing for the delayedPerforms Spell Catcher uses when inserting shorthand expansions. It still happens on Lion, with the latest WebKit nightly.

I didn't really understand (and still may not!) what was going on until recently, as the folks working on Outlook 2011 ran into this and contacted me about it. After a bit of testing, I discovered that the work around I was using for Mail and Safari didn't help at all with Outlook. As Spell Catcher compatibility with Outlook 2011 is truly critical (more so for my company, but certainly for our mutual customers to-be), I decided it was time to dig in a bit and get this reported.

Notes:

Doesn't happen in any other editing view or application (NSTextView, HITextView/MLTE, BBEdit) that implements Check Spelling While Typing - or at least I haven't found a non-WebView case yet.

Doesn't happen with Spell Catcher’s input method component (maybe because DO isn't used, as is the case with InputMethodKit?).

Only reliable solution is to deselect Check Spelling While Typing.

Also reported as bug ID#9330473 on Radar.

Affecting MANY of my customers, definitely a tech support burden for us.

[Mark Rowe (bdash)]

> Also reported as bug ID#9330473 on Radar.

That bug appears to be an unrelated issue that you’ve filed.  Is there another Radar that does describe this issue?

[Evan Gross]

(In reply to comment #1)
> > Also reported as bug ID#9330473 on Radar.
> 
> That bug appears to be an unrelated issue that you’ve filed.  Is there another Radar that does describe this issue?

Whoops, not sure how that happened. Here's the correct ID: #8259081. Thanks for looking into it!