Closed Bug 348271 Opened 18 years ago Closed 15 years ago

Mac OS X key bindings drawn from DefaultKeyBinding.dict are sometimes executed improperly in Camino

Categories

(Camino Graveyard :: HTML Form Controls, defect)

Product:
Camino Graveyard
Component:
HTML Form Controls
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 282097

People

(Reporter: jacobolus, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060804 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1b1) Gecko/20060804 Camino/1.0+

When multiple keystroke bindings are declared in DefaultKeyBinding.dict, the second keystroke is often interpreted both as declared in the binding, and also as a separate one-stroke binding.  For instance, if I bind the combination "control-m, control-a" to insert the "⌘" character, Camino's text widgets will first move to the beginning of the line (control-a), and then insert the ⌘ character (control-m, control-a).

Related bugs:
bug 308824
bug 229473
bug 316459
bug 282097


Reproducible: Always

Steps to Reproduce:
1. Create a DefaultKeyBinding.dict file in ~/Library/KeyBindings/ which includes a multi-stroke binding for which the second stroke is already bound to some other action: for an example, see http://macromates.com/blog/archives/2006/07/10/multi-stroke-key-bindings/
2. Relaunch Camino, and find an html text field, such as the one I'm typing in right now.
3. Try to execute the binding, in this case by pressing "control-m, control-a"

Actual Results:  
The insertion point moves to the beginning of the line, and then a ⌘ glyph is inserted.

Expected Results:  
A ⌘ glyph is inserted, without the insertion point moving at all.

A few months ago, Camino started respecting user key bindings in DefaultKeyBinding.dict.  In general, these bindings work perfectly, and it seems there is support both for multiple-keystroke bindings, and multiple-action bindings (for background see my [article][1]).  Multiple keystroke bindings are buggy however, as described above.

[1]: http://hcs.harvard.edu/~jrus/site/cocoa-text.html
Jacob, have you tested a single-keystroke binding that's different from "standard" ones?  I bet what's happening here is the hard-coded (in platformHTMLBindings.xml) bindings match, and work, but no non-"standard" bindings undefined in pHTMLb.xml work....

If so, this is really bug 282097, and bz gives a hint of code needed to fix it.
Yes, the code was added to actually handle the bindings in a Camino nightly 3-5 months ago, and most of my single-stroke bindings work fine (ASIDE: though not in this bug tracker box, as it uses those stupid html shortcut key things, that I can't ever get turned off; I think I even changed something in about:config at some point, but I don't remember what, and it doesn't seem to have worked).

BUT... you are right that there seem to be some bindings built in that cannot be overridden.  In other words, it seems that Camino is using two sources to determine what to do with a particular binding: a built-in source, and my UserKeyBinding.dict file (and maybe the StandardKeyBinding.dict system file as well).  When these conflict, the built-in bindings take effect.  For instance, to test this I just bound ⌃F to "backward delete", and in Camino, ⌃F still does "move forward".  But if I bind, say, ⌃M to "backward delete", that works fine.

So, the solution to this is simple.  The built-in source should be completely removed, as all of its bindings are either in the StandardKeyBinding.dict system file.  Then items in UserKeyBinding.dict should take precedence over those in StandardKeyBinding.dict, just as they are in every app which uses NSText widgets.
Note, in the previous comment, ⌃ is the ctrl key (^).

Also note: this is not just bug 282097, which was complaining about user-specific bindings being ignored altogether.  Camino actually knows about most of my bindings, and for simple things (apparently those which do not conflict with the built-in bindings), it works splendidly.
Erm, either Camino or Widget:Cocoa, not Widget:Mac.
Assignee: joshmoz → nobody
Component: Widget: Mac → HTML Form Controls
Product: Core → Camino
QA Contact: mac → form.controls
Version: Trunk → unspecified
Jacob, has anything here improved (gotten worse) in the last year (sorry :( ) in Camino trunk nightlies?  Do you see the same thing in Minefield nightlies?

I'm really puzzled as to how this is working at all for you, given that all text fields in web content are Gecko and not native, but maybe ChildView implements enough of the right selectors?

Also, have you ever tried removing the platformHTMLBindings.xml file from Camino.app/Contents/MacOS/chrome/embed.jar!content/global/ and seeing if your bindings (and the OS ones) work then?
Jacob, can you please reply to comment 5?
Whiteboard: [CLOSEME - 6/1]
Hey.  I'm obscenely busy for the next few days.  Can I flag the email bugzilla sent me, and get back to you in a week or 10 days? :)
How about now? :)
Jacob visited on irc tonight and looked at this, and we're now at the point where our behavior is a straight dupe of bug 282097.  No clue about what caused the odd partly-working behavior to begin with, but it's now all gone.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.