482457 - new conflicts with SpellCatcher (related to input method handling)

Status: RESOLVED INCOMPLETE

(Core :: Spelling checker, defect)

Description

[Dan Doernberg]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7

Two problems, summarized first and then elaborated on below [Note-- I submitted a bug report before about SpellCatcher input methods that was accepted: https://bugzilla.mozilla.org/show_bug.cgi?id=442660].

  1. failure to expand SpellCatcher abbreviations without leading space (sometimes/some sites)
  2. crashes when expanding an abbreviation (new thing, perhaps related to new 3.0.7?)



1. Here's my email conversation with Evan Gross, developer of SpellCatcher:

   DanD---Here's a sample page/site for which Safari has no problem expanding data put into a data entry form but in Firefox (latest version) I have to input a leading space first before SpellCatcher can expand the abbreviation:  
https://www.allaboardtoys.com/createaccount.aspx?checkout=true
Any thoughts on what system parameter might be the problem??

  EvanG-- It's a bug in Firefox 3. Only the developers working on FF3 can fix this. Nothing else factors into this problem.


2. I input "jackson" which is an abbreviation I have that automatically capitalizes the word, i.e. turns it into "Jackson". Firefox immediately crashed (no expansion performed) as soon as I put the space after "jackson". I reloaded Firefox, entered the same lowercase word, and it immediately crashed again. I then reloaded Firefox a third time, turned off SpellCatcher, and then had no crash when I typed in "jackson".


Reproducible: Sometimes

Comment 1

[Mike Connor [:mconnor]]

It'd sure be nice if he actually had an explanation instead of simply blaming us.  It's not our job to troubleshoot all add-on failures or crashes they cause unless the developer can tell us what they're calling in our code that's crashing.  Given that it's a closed source, proprietary app, we can't really see what's happening short of guesswork, and we don't do that.

If Evan can identify what that code is doing when Firefox crashes (especially what APIs he's using) then we should get that information in a bug saying something like "crash when calling Foo with Bar" or whatnot.

In general, most crashes from binary components calling into Firefox are due to using private APIs or linking against classes that aren't even exposed as APIs, which eventually runs into problems when the APIs change due to security fixes, etc.

Comment 2

[Evan Gross]

(In reply to comment #1)
> If Evan can identify what that code is doing when Firefox crashes (especially
> what APIs he's using) then we should get that information in a bug saying
> something like "crash when calling Foo with Bar" or whatnot.

OK, sorry to take so long to get to this. I've never seen Firefox crash as Dan describes.

But the real problem that's affecting our mutual customers is that Firefox 3.x doesn't handle mouse down events in the manner required by input methods (in general), Spell Catcher needs to know when a mouse click changes the insertion point/selection/focused text area so it can reset its internal state appropriately. Note that Spell Catcher doesn't maintain an active inline input session - other input methods that do *also* need to know about mouse down events (for their own reasons).

Ideally, even in the absence of inline input, mouse downs in the currently focused text area should call FixTSMDocument(). If there is an inline input area, and the mouse is clicked inside that area, the Text Services Manager should automatically pass the event to the input method for handling. Provided the app has properly called TSMSetInlineInputRegion() to inform TSM, this will happen. Otherwise, it's up to the app to call TextServiceEventRef() to inform the input method.

The reality is that some older Carbon apps don't do the above quite right, so Spell Catcher's input method component installs a CarbonEvent handler on GetEventDispatcherTarget() to look for mouse events. If a mouse down occurs in the window's content, it handles it as though FixTSMDocument() was called.

Firefox 2 did properly call FixTSMDocument() when a mouse click caused a change in the focused text area (field, whatever). It did not call FixTSMDocument() when a mouse down in the currently focused text area caused the selection to change in the absence of an inline session. But Spell Catcher is able to "see" these mouse events in the handler it installs on the EventDispatcherTarget.

In Firefox 3.x, all mouse downs are essentially swallowed, and therefore completely "invisible" to Spell Catcher (or any input method component) - at least in the absence of inline input. FixTSMDocument() is not even called when the mouse down changes the focus for keyboard events. When there is an inline session, FixTSMDocument() is always called - even if the event is within the inline area (instead of being sent to the input method for handling). But the kicker is that they aren't seen by my CarbonEvent handler, as is the case for Cocoa apps in general. But since all standard Cocoa text editing views handle events properly for input methods, that CarbonEvent handler isn't really needed (as a fallback) as it is with some Carbon apps.

So the end result is that Spell Catcher has no way to know that a mouse click caused a change in the selection or focused text area, and all the keystrokes it's tracking are seen as "running-together". Hence the need to for the original reporter to have to prefix a shorthand abbreviation with a space, or for users to otherwise force Spell Catcher to realize that the following keystroke should begin a new word.

I believe there are similar issues with tab key handling, although not quite as serious for the user as Spell Catcher sees them as word separators. In other words, tabbing to change the focused text area/field doesn't call FixTSMDocument() - at least in the absence of inline input. In fact, what *should* happen is the creation of a new TSMDocument. Since this is often impractical with lighter-weight text fields (a shared field editor), if the TSMDocument is re-used, a fix/deactivate/activate should be done by the app.

Anyway, hope that makes sense, if you have questions fire away.