442660 - Firefox 3 "doesn't conform to general Mac OS X text input guidelines" (input methods) and breaks SpellCatcher)

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Dan Doernberg]

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

SpellCatcher has been a highly respected Mac utility for 10+ years... the developer knows his stuff by all accounts.

Spellcatcher works fine with almost every app on the Mac platform, including Firefox 1 and 2... but isn't working reliably with Firefox 3. The Spellcatcher devloper posted the following on his Forum message board:

The specific problem here, and why you observe this somewhat unpredictable behavior, is caused by two different bugs:

1. Firefox "eats" the tab key (at least, perhaps other control keys as well), handling it in such a way that input methods never get to see it. This is a real problem because tab is considered a word separator, and is used by Spell Catcher to trigger various interactive features and behavior. Preventing an input method from handling *any* keystroke is seriously frowned-upon.

2. Firefox does not pass mouse events through to input methods. There are two ways mouse events should be handled as far as an input method is concerned. One is for editing in any open inline input area (Spell Catcher does not "do" inline input), the other is to signal to the input method that the selection has changed, and it needs to finalize whatever needs to be done due to this. Spell Catcher uses both to reset the state of interactive checking. Because Spell Catcher doesn't get notified of mouse events, typing appears to "run-together" whenever you click to change the insertion point or edited text area, then begin typing again.

These two bugs cannot be worked around on the input method side. The application must be fixed so that it conforms to general Mac OS X text input guidelines.

[end Quote]

PS--- I'm not technical enough to know if this might be related to this old bug reporting input method issues... doubt it, but just in case: 269207

Reproducible: Sometimes

Steps to Reproduce:
1.  Enter a Spellcatcher abbrevication (text) into Firefox's URL window. An example: /g + space character
2.  that should make Spellcatcher expand it per the expansion datathe? I maintain in Spellcatcher; it should expand to: http://www.google.com

Actual Results:  
Firefox often (not always) fails to perform the expansion, "/g" remains in the URL window.

Expected Results:  
It should have expanded to http://www.google.com

You might try contacting Evan Gross, the developer, at Rainmaker Inc.; he is an expert in Mac (and perhaps Windows also) input methods and I'm guessing would be happy to help make Firefox conform to Mac specs.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

See also bug 303248 about TypeIt4Me, though it's a different type of failure.

I also think this could be a regression within Cocoa widgets itself (as opposed to just a regression between Fx2 and Fx3n due to the Carbon-Cocoa switch), because we used to have bugs on SpellCatcher interaction in Camino and smfr fixed them--at least to the point that reporters and Evan stopped replying (see bug 198033).

This bug should probably be closed and split into two different reports, though: one about item 1 and a second about item 2.  (Item 1 sounds like a regression from smfr's fix in bug 198033.)

Comment 4

[Steve Sweitzer]

In my case, I get a double expansion. s1 + space should result in "Steve" instead I get Steve 쀀쀀᫑
a1 + space should result in 2210 Kessler Blvd E Dr instead I get a12210 Kessler Blvd E Dr 2210 Kessler Blvd E Dr  
(In reply to comment #1)
> See also bug 303248 about TypeIt4Me, though it's a different type of failure.
> 
> I also think this could be a regression within Cocoa widgets itself (as opposed
> to just a regression between Fx2 and Fx3n due to the Carbon-Cocoa switch),
> because we used to have bugs on SpellCatcher interaction in Camino and smfr
> fixed them--at least to the point that reporters and Evan stopped replying (see
> bug 198033).
> 
> This bug should probably be closed and split into two different reports,
> though: one about item 1 and a second about item 2.  (Item 1 sounds like a
> regression from smfr's fix in bug 198033.)

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #0)
> 1. Firefox "eats" the tab key (at least, perhaps other control keys as well),
> handling it in such a way that input methods never get to see it. This is a
> real problem because tab is considered a word separator, and is used by Spell
> Catcher to trigger various interactive features and behavior. Preventing an
> input method from handling *any* keystroke is seriously frowned-upon.

Any chance this is the same thing as/related to the blackhole in bug 379199?

Comment 6

[Stuart Morgan]

(In reply to comment #5)
> Any chance this is the same thing as/related to the blackhole in bug 379199?

I don't know enough about input methods to know where they fit into the event path.

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

See also bug 198033 (which may be the existing bug about comment 0 point 1) and bug 308865 (where smfr last fixed some of the IME issues described in bug 198033).

Comment 8

[Michelle Funches - QA]

Reproducible 
Version 	47.0.1
Build ID 	20160623154057
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Moving all open Keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Comment 10

[Peter Magyari (Desktop QA)]

Hi Dan,

I know this is a very old report, have you by any chance seen this issue occur on the latest Firefox version?

Thank you!

Comment 11

[Dan Doernberg]

SpellCatcher is now (veyr regretably) defunct, so have not seen this behavior in recent years...
Thank you for the follow-up, but should be quite safe to resolve this ticket.

Comment 12

[Peter Magyari (Desktop QA)]

Thank you for the update!