Closed
Bug 198033
Opened 21 years ago
Closed 29 days ago
Camino eats certain keystrokes so Input Methods cannot see them.
Categories
(Camino Graveyard :: General, defect, P2)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: spamburke, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6 Camino 0.7 eats keystrokes such that Input Methods cannot see them. This is especially problematic for programs such as Spell Catcher, which relies on being able to see what keys were just typed. As an example, if I type h-e-l-g-delete-l-o, the inpute methods sees this as 'helglo' rather than 'hello' -- i.e., the "delete" was eaten. This happens in text boxes within pages, but does not seem to happen in the url bar. The problem (for me) is that this triggers Spell Catcher to see a misspelling when it's already been corrected. I'm sure that this also causes numerous other problems, but I'm not aware of them. I have verified that this is a problem in the most recent nightly build that I can get to launch (3/14/03; I can't get the more recent builds, up through 3/17/03 to launch). I have also verified that this is a problem in the most recent stable release of Mozilla (1.3), but that it has been fixed in Mozilla 1.4a. However it was fixed, this fix need to be incorporated into Camino. As a side note, this is not a general browser problem, as it only seems to happen in the Mozilla family of browsers (Safari, OmniWeb, Explorer are fine). Reproducible: Always Steps to Reproduce: 1. Begin typing in a text box. 2. Make a typo. 3. Delete/fix the typo. 4. The delete keystroke gets eaten. Actual Results: Exactly as described, the delete keystroke fixes what's on the screen, but is 'invisible' to the Input Method. Expected Results: It should have made the Input Method 'see' exactly what appears onscreen.
Comment 2•21 years ago
|
||
no, not a duplicate of that bug John Burke--can you explain what you mean by "4. The delete keystroke gets eaten."; what should be happening? Camino isn't deleting any OS events.
Comment 3•21 years ago
|
||
By "keystroke being eaten" it means that (most likely) Camino is handling these keys (backspace, tab, return) in a rawkeydown handler and returning noErr (or some similar scenario). This means that the keystroke never gets "seen" by TSM, so it is never sent to any active input method. My product (Spell Catcher X) implements as-you-type features via an IM, so (as described in the initial report) this causes a (rather major) problem if the user types one of these characters. NOTE that SC will either "fix" every character the user types (by sending an UpdateActiveInputArea event to the app) or return to the app that it didn't handle a character. This means that it works in basically a "direct input" mode - there is never any inline text. This is easily reproduced, unfortunately we don't yet have a demo version of SCX you can test with. HOWEVER, the same behavior happens with TypeIt4Me, and he does have a demo version. Just make sure that Camino isn't in the "TSM apps" list (this forces direct input). See http://homepage.mac.com/rettore/ty/ for info on TypeIt4Me. As previously stated, this WAS a problem with Mozilla 1.3a, but is no longer a problem with 1.4a. So *something* was modified that either directly addressed this issue or had the (desirable) side-effect of fixing the problem. Hope this clarifies things, if you have more questions feel free to ask. Evan Gross (Spell Catcher author)
Comment 4•21 years ago
|
||
so if the author says it's fixed, i'm marking it as so.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Comment 5•20 years ago
|
||
(In reply to comment #4) > so if the author says it's fixed, i'm marking it as so. No No No No No!!!! This bug is not at all fixed! The Mozilla folks had the same bug, prior to the release of version 1.4a! They fixed it - it is NOT fixed in Camino (even as of the latest nightly build March 11, 2004). This is a truly nasty behavior - it must be addressed. You should be able to incorporate their fixes - not sure why this hasn't happened. Again, this is a really bad bug. It means that all input methods are basically incompatible with Camino. You can see for yourself by download the trial version of Spell Catcher X 10.1 from: <http://www.rainmakerinc.com/downloads/> Again - Camino does not let control characters through to input methods - it is handling the raw events itself - totally against all Apple guidelines! Input methods will never see backspaces, tabs, returns, forward deletes that the user types into any text area on a rendered page (not a problem for the toolbar textfields). This makes it virutally unusable with input methods. Please open this bug again - it's got to be fixed for version 0.8.
Comment 6•20 years ago
|
||
This bug needs to be reopened. It has not been fixed. Camino still swallows keystrokes and does not pass them to Input Methods.
Updated•19 years ago
|
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•19 years ago
|
Assignee: saari → sfraser_bugs
Status: REOPENED → NEW
Priority: -- → P2
Target Milestone: --- → Camino1.0
Comment 7•19 years ago
|
||
This is comment 3 wrapped so we can read it: By "keystroke being eaten" it means that (most likely) Camino is handling these keys (backspace, tab, return) in a rawkeydown handler and returning noErr (or some similar scenario). This means that the keystroke never gets "seen" by TSM, so it is never sent to any active input method. My product (Spell Catcher X) implements as-you-type features via an IM, so (as described in the initial report) this causes a (rather major) problem if the user types one of these characters. NOTE that SC will either "fix" every character the user types (by sending an UpdateActiveInputArea event to the app) or return to the app that it didn't handle a character. This means that it works in basically a "direct input" mode - there is never any inline text. This is easily reproduced, unfortunately we don't yet have a demo version of SCX you can test with. HOWEVER, the same behavior happens with TypeIt4Me, and he does have a demo version. Just make sure that Camino isn't in the "TSM apps" list (this forces direct input). See http://homepage.mac.com/rettore/ty/ for info on TypeIt4Me.
Comment 8•19 years ago
|
||
So I assume that the call to -interpretKeyEvents is the one that sends key events to input managers. Does that mean that we should call -interpretKeyEvents even when the key event is for the delete key?
Status: NEW → ASSIGNED
Comment 9•19 years ago
|
||
(In reply to comment #7) Just in case anyone's interested, we do indeed have a trial version now (14 days limited, can be licensed to the "real thing"): http://www.rainmakerinc.com/downloads/
Comment 10•19 years ago
|
||
(In reply to comment #8) I don't have a lot of experience (getting there) with the AppKit side of text input management, but my guess would be yes, you need to give the input management a crack at every single key event. Easy to see if worked when Spell Catcher is active by truning on Auto-Show Suggestions, typing an error, then backspacing into it and seeing if the window automatically closes. Same goes for returns, see if typing a valid word, return, and another valid word does NOT result in Spell Catcher thinking it's a run-together error word.
Comment 11•19 years ago
|
||
Evan: should I be able to use the Return key to enter the selected word from the popup-suggestions list? If I do, the Return ends up going into Gecko, and going into the text field or submitting the form (ack!). I did note the "Spacebar chooses selected suggestion", and the spacebar works OK.
Comment 12•19 years ago
|
||
(In reply to comment #11) This is as-designed - return and enter (and optionally spacebar) will choose a completion. Whether the trigger gets sent along with the completion depends on the setting of the "Always suppress the keystroke that chooses a completion" box (Interactive pane, Completion tab). My guess is you'd want to turn it off for Camino. I don't think this is relevant to the problem at hand, though... As for your question in comment #8, maybe take a look at -[NSInputServiceProvider wantsToInterpretAllKeystrokes]. I say *maybe* because, well, when dealing with input methods, you just never know...docs can be sparse in many areas.
Moving the IME bugs to 1.1 :-(
Target Milestone: Camino1.0 → Camino1.1
Comment 14•19 years ago
|
||
I think this is mostly fixed anyway. For every keyDown:, we call interpretKeyEvents (as long as there is a firstResponder).
Moving IME-related bugs to Camino 1.2 :(
Target Milestone: Camino1.1 → Camino1.2
Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Comment 17•16 years ago
|
||
Could someone re-test thing in trunk Camino and Minefield, and see where things stand after all the key handling changes that have happened?
Assignee: sfraser_bugs → nobody
Status: ASSIGNED → NEW
QA Contact: winnie → general
Status: NEW → RESOLVED
Closed: 21 years ago → 29 days ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•