Errors with simple key rebindings

VERIFIED WORKSFORME

Status

()

Core
Keyboard: Navigation
VERIFIED WORKSFORME
16 years ago
15 years ago

People

(Reporter: Mike Cannon, Assigned: David Hyatt)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; m18)
Gecko/20010110 Netscape6/6.5
BuildID:    2001122617

Two custom key bindings are specified in .../res/builtin/userHTMLBindings.xml
requesting two keys to be bound to two different commands.  The result
is that both keys show the same behavior. WHICH behavior depends on
they order they are given in userHTMLBindings.xml

Similar things happen for a variety of other bindings,
with and without this preference set in user.js:  
user_pref("ui.key.menuAccessKey", 0);

Reproducible: Always
Steps to Reproduce:
1.Install .../res/builtin/userHTMLBindings.xml   (see below)
2.Restart Mozilla
3.Position any html page so it has room to scroll both up and down,
  and focus on the content, not in any input field.
4.Press ^X and ^Z.

Actual Results:  I get the *same* behavior mapped to the keys ^X and ^Z, which
of course is not what is specified. Depending on the *order* in which the two
bindings are listed in userHTMLBindings.xml, the behavior is either
cmd_scrollLineUp or cmd_scrollLineDown.

================================================================
.../res/builtin/userHTMLBindings.xml:

<?xml version="1.0"?>

<!-- Create a file called userHTMLBindings.xml and link it into -->
<!-- res/builtin. There's no need to add anything to userChrome.css. -->
<!-- In order to work correctly, this file must live in the -->
<!-- res/builtin directory of the mozilla tree. -->

<bindings id="htmlBindings"
   xmlns="http://www.mozilla.org/xbl"
   xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

  <binding id="editorUser">
    <handlers>
      <!-- 
      <handler event="keypress" key="w" modifiers="control"
             command="cmd_deleteWordBackward"/>
       -->
    </handlers>
  </binding>

  <binding id="browserUser">
    <handlers>

      <!--  
       With the following two handlers I get the *same* behavior
       mapped to the keys ^X and ^Z, which of course in not correct.
       Depending on the *order* of the two bindings the behavior is
       cmd_scrollLineUp or cmd_scrollLineDown.
       -->

      <handler event="keypress" keycode="x" modifiers="control" 
               command="cmd_scrollLineUp" />

      <handler event="keypress" keycode="z" modifiers="control"
               command="cmd_scrollLineDown" />

    </handlers>
  </binding>


</bindings>

================

Comment 1

16 years ago
This is bad -- akkana, who should get it?
Assignee: aaronl → akkana

Updated

16 years ago

Comment 2

16 years ago
That's Hyatt's area.  It's strange that it would happen just in this case,
though, and hasn't been noticed in our existing bindings.
Hyatt, any ideas?
Assignee: akkana → hyatt
(Assignee)

Comment 3

16 years ago
Looks like a bug, but I'm a little skeptical, since I would think we'd have run
into this in our own code. :)
(Reporter)

Comment 4

16 years ago
I would be happy to look into this further, say by examining the key/command
binding table, or verify it by other means.

Can you tell me where to find that table (for html content), for instance?

Thanks,

Mike
Reporter: still happenes on RC1 or another recent build? If not, set the bug to
"worksforme"
wfm, as nobody can reproduce it. reopen if you can.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
mass-verifying WorksForMe bugs.

reopen only if this bug is still a problem with a *recent trunk build*.

mail search string for bugspam: AchilleaMillefolium
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.