when a button has focus, enter key doesn't fire the button's oncommand handler

RESOLVED FIXED in mozilla0.9.6



17 years ago
10 years ago


(Reporter: Suresh, Assigned: Joe Hewitt (gone))



Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: fix in hand)


(1 attachment)



17 years ago
If you _Tab_ tgh keyboard and focus on a button and hit Return key, the 
oncommand handlers doesn't fire.

Comment 1

17 years ago
nominating for nsbeta1. I'm pretty sure there are lots of places where the 
buttons have already focus and user prefers to use just the keyboard.
Keywords: nsbeta1
updating summary.

cc'ing joe, blake and hyatt.  this might be a well known dup.
Summary: Return key's doesn't fire oncommand handlers. → when a button has focus, enter key doesn't fire the button's oncommand handler

Comment 3

17 years ago
Do you really mean HTML Form Controls?  If you're talking about oncommand, it 
must be xul.  Where did you test?
right, this was in xul.

suresh tabbed so that focus was over a button, and then hitting enter didn't
"fire" the button.

a related problem is that on dialogs that use the ok / cancel button dialog
overlay, if the cancel button has focus, hitting enter will fire the ok button.

we've got a keyset in the overlay that maps enter to ok and escape to cancel. 
that's the right thing, but just as enter is "grabbed" by text fields, it seems
like buttons should "grab" enter when they have the focus.

Comment 5

17 years ago
Blake, if you think this bug shd be in a diiferent component, please feel free
to change it. 

ok/Cancel issue that Seth mentioned in the previous comment is covered in bug

Comment 6

17 years ago
Okay, I see this now. Fix coming.
Assignee: rods → blakeross
Component: HTML Form Controls → XP Toolkit/Widgets: XUL
QA Contact: vladimire → jrgm

Comment 8

17 years ago
Hmm, so that makes it so that when a button has focus, and Enter is pressed, 
the MouseClicked() is called. 

But, that doesn't seem to work. For example, open the preferences dialog. 
For the pref-navigator.xul panel, set the caret in the Location: textfield. 
Then TAB twice, so that focus is on 'Choose File...', then hit Enter. 
The dialog does not come up (but it will on a actual mouse click).

That element has this XUL defined:

<button class="dialog" label="&browseFile.label;"   
  id="browserChooseFile" pref="true" preftype="bool"

Comment 9

17 years ago
Works for me (the other problem still exists, so Open will have to be disabled 
for it to work...otherwise Open will trigger.)

Comment 10

17 years ago
Er, nevermind, I thought you were referring to the Open Web Location dialog. 
Anyways, the case you mention worked fine for me in winXP.

Comment 11

17 years ago
Well, don't know why, but this fails for me (doesn't get a |container|
in PresShell::HandleDOMEventWithTarget.

Comment 12

17 years ago
Strange.  I'll try it on my work machine, and if it works there, you can come 
down and see that I'm not lying :-) (and if it doesn't work there, I'll shut 

You tried on win2k?
Whiteboard: fix in hand
Target Milestone: --- → mozilla0.9.2

Comment 13

17 years ago
Yes, I was failing this way on win2k. Your patch does its job, but it goes 
wrong further down the road and the file dialog (in this example) doesn't come 
up. However, same button with a mouse succeeds at the same point in the code
that the keypress is failing (in PresShell::HandleDOMEventWithTarget.)

Comment 14

17 years ago
Crap. You're right, it's not working here either.

I'm guessing the keystroke isn't going to the button, but one of its parents, as
its apparently intended to.

I had other changes at home that I guess affected this (luckily I have my tree
here ;-)  I'll come up with a new patch, it seems like this kind of thing should
be in xbl anyways.


17 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3


17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4


17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 15

17 years ago
*** Bug 67923 has been marked as a duplicate of this bug. ***
Keywords: access
see also bug 63728.  In short, on windows enter should trigger focused button. 
On other platforms, enter should trigger _default_ button and space should
trigger focused button.
Depends on: 63728

Comment 17

17 years ago
I made this work with the <wizard> binding... this could just be built into
<dialog> the same way, so you could just give this bug to hewitt... 


17 years ago
Keywords: oeone

Comment 18

17 years ago
Boris: Are you sure about Windows? I thought the Enter key was supposed to 
always execute the "default" button, even if it isn't focused. I thought the 
"space" key is what fires the focused button (or other widget), independent of
 the "default" button.
I'm just passing on what the UI spec people said in bug 63728.  :)

Comment 20

17 years ago
bz correctly repeated the info. on windows enter indeed triggers the fccussed 
button or the default button when there is no focussed button.

Comment 22

17 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6


17 years ago
Blocks: 104166

Comment 23

17 years ago
hewitt was working on stuff like this.
Assignee: blakeross → hewitt

Comment 24

17 years ago
Just re-tested blake's patch, and it does indeed work, even in the case that
jrgm had earlier mentioned as not working.


Comment 25

17 years ago

Comment 26

17 years ago
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 27

17 years ago
This description isn't entirely accurate.  I get the same symptom on Javascript
Confirm function using only the mouse.  I got here on a chain of "dupes" that
may be a bit optimistic.

Try this uri:http://www.w3schools.com/js/tryit.asp?filename=tryjs_confirm

Click "OK" and the script reports you clicked cancel.

STILL ALIVE IN 2001-11-08-03

Comment 28

17 years ago
But the code used is:
if (name == true)

Enclose true in quotes like this:
if (name == "true")

and it works as expected.

Comment 29

17 years ago
Cool!  Considering the source URL, somebody's gonna have a red face when they
get my report of this.


10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.