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

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.

updating summary. cc'ing joe, blake and hyatt. this might be a well known dup.

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.

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 84589.

Okay, I see this now. Fix coming.

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;" accesskey="&browseFile.accesskey;" oncommand="selectFile();" id="browserChooseFile" pref="true" preftype="bool" prefstring="pref.browser.homepage.disable_button.select_file" prefattribute="disabled"/>

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

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

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

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 up). You tried on win2k?

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.)

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.

*** Bug 67923 has been marked as a duplicate of this bug. ***

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.

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...

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. :)

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

Bug 63728 got fixed. People should retest.

->0.9.6

hewitt was working on stuff like this.

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

r/sr=hyatt

fixed

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

But the code used is: if (name == true) Enclose true in quotes like this: if (name == "true") and it works as expected.

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