Closed Bug 23450 Opened 25 years ago Closed 25 years ago

keybindings set in XUL hijack keyboard events in focussable elements

Categories

(Core :: XUL, defect, P4)

x86
Windows 95
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: bugs, Assigned: hyatt)

Details

Try this: browser: edit->Preferences->Navigator focus the homepage url text field hit enter observe that the dialog closes. Now, the homepage url text field had focus, not the dialog OK button. (of course, even if OK was focussed, you couldnt tell, since that isn't hooked up yet....) this may not sound that important in the context of the homepage url field, but take another example: I am revising the "What's Related" panel so that it contains a treeview-list of the ignored sites. There will be a text field into which the user can type a domain name, and either click Add or hit enter to have it added to the list of WR-not-loaded domains. However, hitting enter closes the dialog. d'oh. here's some sample code to give you an idea of what I'm doing... <html:input ... onkeypress="DoEnabling( event );"/> function DoEnabling( aEvent ) { if( aEvent && aEvent.which == 13 ) { AddDomain(); } } The hijacking is done by the platformDialogOverlay's key bindings, which are: <keyset id="keyset"> <key keycode="VK_ENTER" oncommand="doOKButton()"/> <key keycode="VK_RETURN" oncommand="doOKButton()"/> <key keycode="VK_ESCAPE" oncommand="doCancelButton()"/> </keyset> I would say this is non-essential for now, but damned annoying and worth completing for final. (not to mention some users use the enter key to toggle or select dialog elements like tree selections etc. )
Assignee: trudelle → saari
Priority: P3 → P4
Target Milestone: M15
I don't know if the implementation is wrong here, but the question of whether the Enter key bonks the default button should depend on what the current focus is. When focussed in a single line text field, I expect to be able to type the text, then hit Enter to dismiss the dialog. When focussed on the non-leaf node of a tree, I expect Enter to expand the tree. I believe this is what happens on most popular apps on most platforms. The What's Related scenario you describe sounds very similar to the DNS and Gateway tabs in the Win98 TCP/IP Properties dialog. There, entering the numbers and hitting Enter dismisses the dialog without doing the Add. This seems wrong to me, but may be what users expect on platforms where this is a convention. reassigning to saari as p4 for m15
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Hyatt, is a textfield XBL binding for enter the right way to fix this?
Assignee: saari → hyatt
Ben. You must call preventDefault() on the event. This will prevent the default action (closing up the dialog) from happening. There is no bug here.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
sorry fot the spam, changing QA contact.
QA Contact: paulmac → jrgm
It is implemented correctly marking as verified.
Status: RESOLVED → VERIFIED
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.