- launch mozilla (9/14/00-5pm) - open "open web location" dialog - hit return expected: - since the "Open" button is disabled, nothing should happen actual: - dialog dismisses.

if the button is disabled, it better not do anything. i'm sure this happens in other places.

who should own this?

Eek! And this too ... if I TAB to set the focus on the Cancel button and then press the Enter/Return key, the OK button handler is called, not the Cancel button handler. This applies to any dialog. This would be ben's I believe, but I assume Mike gave it to Don for a purpose (like, there _are_ other people who could upgrade/fix this).

and it happens on linux and winnt. bluh.

i don't even need to tab... just point'n'click the Cancel button, and it behaves as if active (ie, like the OK button). whee!

nsbeta3-

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy

Windows too, both on the original problem and on the problem John Morrison mentioned. Mac -> All/all. Adding dependency on bug 63647 (Button should have focus by default in common dialogs). Also, fixing this bug might fix bug 59044 ([linux] hitting enter in dialog boxes can cause crash).

nav triage team: Should fix this, marking nsbeta1, mozilla0.9, reassigning to pchen

Why P5/Future? Grandma doesn't die, but if the 'Cancel' button has focus, and the user hits the 'Enter' key, the OK action will occur -- i.e., they used the UI correctly to bail out of a dialog, and instead had the opposite action occur (which can't be reversed).

jrgm, the (separate) problem you describe is now covered by bug 67923.

We could put this stuff in a <broadcaster/>, but I'd just as soon not have to include it in every file that uses dialogOverlay (or depend on the fact that most files pull in <broadcasterset/>). Also, we could do the same for the Cancel button, but I don't think it's necessary -- I can't think of any case where Cancel would be disabled, and I think Escape should always do the cancel action and close the dialog. cc'ing alec for sr...

I'm fine with that too. sr=alecf

bug 68649 is asking for [macos] cmd-. to be mapped to cancel after discussing this bug w/ blake on irc, i think we should go with some form of broadcaster.

I started doing that, and I'm now into 35+ files and many more to go. I don't think that adding a broadcaster to over 30 files (and modifying lots of other code, like enabling/disabling of the buttons, to use the broadcaster instead) just to avoid a couple lines of code duplication is a good idea. Nor do I think that forcing everyone who uses dialogOverlay.xul to remember to add the broadcaster for the buttons to work is a good idea.

Fix checked in.

vrfy fixed using 2001.05.29.0x comm bits on mac, linux and winnt.