Open
Bug 90318
Opened 23 years ago
Updated 2 years ago
Triggering a XUL accesskey should "push" the widget
Categories
(Core :: XUL, defect)
Tracking
()
NEW
mozilla1.2alpha
People
(Reporter: hwaara, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: helpwanted)
If I trigger an accesskey for example a button, then to make it more visible that the button's action is actually fired we should push the button down (probably with some sort of timeout to make it visible, 200 ms or so). This is done in MacOS, and many usability books I've read strongly recommends visual feedback (like this) for usability.
Comment 2•23 years ago
|
||
An alternative would be to think of the keydown event as a mousedown event and the keyup as a mouseup. So when you'd press the key, it would push the button, and when you let go of the key, it would fire oncommand.
Reporter | ||
Comment 3•23 years ago
|
||
Good idea!
Reporter | ||
Comment 4•23 years ago
|
||
As long as it doesn't break auto-key events (like textfields receive to input more than one character when you hold the key pressed down for some time)
please don't try to use mouse events. the key repeat stuff will totally confuse everything.
Comment 6•23 years ago
|
||
Hakan: have you been running with the patch from bug 959 in order to determine that we don't do this? All: We already do this for XUL buttons, for example pressing OK or Cancel in the Find dialog using the space bar. In theory we should be able to extend that code instead of starting from scratch.
Reporter | ||
Comment 7•23 years ago
|
||
Dean: I talked to Chad before filing this bug.
Comment 8•23 years ago
|
||
I no longer have time for these. Anyone else want to take them?
Comment 11•23 years ago
|
||
We want this for 1.0. I will probably get around to it before that, but targetting 1.0 for now.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Comment 13•23 years ago
|
||
nsbeta1, -> 1.0
Keywords: nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 14•23 years ago
|
||
Anyone have a pointer to where Space-presses-a-XUL-button takes place? I can try to leverage that code. <OT> We need visual feedback when pressing space on standard HTML form buttons, and I'm sure there's already a bug. Anyone know the bug for that? </OT>
Comment 15•23 years ago
|
||
nsButtonBoxFrame.cpp. This is easy, just set the content state at the appropriate times (keydown, keyup).
Comment 18•23 years ago
|
||
"This is easy, just set the content state at the appropriate times (keydown, keyup)." I don't think so. The handling for Space uses keydown and keyup. The fix for bug 959 doesn't appear to trigger keypress events. As far as I can tell, the fix uses nsIDOMXULElement->Click(), which should call nsXULElement::Click(), which sends three events in succession: NS_MOUSE_LEFT_BUTTON_DOWN, NS_MOUSE_LEFT_BUTTON_UP, and finally NS_XUL_CLICK. It doesn't look like there's any time for message painting between the button down and button up messages. Would it be as simple as forcing a reflow after the NS_MOUSE_LEFT_BUTTON_DOWN event is sent?
Comment 19•23 years ago
|
||
You may be able to get this to work by posting events on the event queue, instead of dispatching them manually.
Comment 20•23 years ago
|
||
Could be. nsXULElement::Click calls nsXULElement::HandleDOMEvent() directly.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Updated•16 years ago
|
Assignee: jag → nobody
Updated•14 years ago
|
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•