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

NEW
Unassigned

Status

()

P3
major
10 years ago
2 years ago

People

(Reporter: dan, Unassigned)

Tracking

({regression})

1.9.0 Branch
x86
Mac OS X
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tpi:+, URL)

(Reporter)

Description

10 years ago
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.

Updated

10 years ago
Assignee: nobody → joshmoz
Component: OS Integration → Widget: Cocoa
Product: Firefox → Core
QA Contact: os.integration → cocoa
Version: unspecified → 1.9.0 Branch
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.)
Keywords: regression
Duplicate of this bug: 443622
Duplicate of this bug: 456768

Comment 4

10 years ago
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.)
(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

10 years ago
(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.
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).

Updated

9 years ago
Assignee: joshmoz → nobody
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

Updated

2 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

2 years ago
Priority: -- → P3
Hardware: PowerPC → x86
Whiteboard: tpi:+
You need to log in before you can comment on or make changes to this bug.