Closed
Bug 348867
Opened 18 years ago
Closed 18 years ago
[ally] up/down keys behavior in mimmal select1 for xhtml
Categories
(Core Graveyard :: XForms, defect)
Core Graveyard
XForms
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: surkov, Assigned: surkov)
References
Details
(Keywords: fixed1.8.0.8, fixed1.8.1.1)
Attachments
(3 files, 1 obsolete file)
From bug 348053:
The up/down arrow keys are doing double duty in terms of navigating the caret
and changing item selection.
(In reply to comment #0)
> From bug 348053:
>
> The up/down arrow keys are doing double duty in terms of navigating the caret
> and changing item selection.
>
? Isn't that what they are supposed to do? What do you want to change?
|
Assignee | |
Comment 2•18 years ago
|
||
|
|
Assignee | |
Comment 3•18 years ago
|
||
(In reply to comment #1)
> ? Isn't that what they are supposed to do? What do you want to change?
>
I guess behaviour should be consistent with xul:menulist[editable="true"] behaviour. Up/down arrow keys shouldn't change caret position.
|
|
Assignee | |
Comment 4•18 years ago
|
||
|
|
Assignee | |
Comment 5•18 years ago
|
||
(In reply to comment #3)
> I guess behaviour should be consistent with xul:menulist[editable="true"]
> behaviour. Up/down arrow keys shouldn't change caret position.
>
And I guess we shouldn't open select1 on click and we should open select1 on up/down keys.
Summary: up/down keys doing double duty in mimmal select1 for xhtml → [ally] up/down keys behavior in mimmal select1 for xhtml
|
|
Assignee | |
Comment 6•18 years ago
|
||
Attachment #234675 -
Flags: review?(Olli.Pettay)
|
|
Assignee | |
Updated•18 years ago
|
Status: NEW → ASSIGNED
|
||
Comment 7•18 years ago
|
||
Comment on attachment 234675 [details] [diff] [review]
patch
> // ..other key events are handled in keyUp, because otherwise
> // this.inputField.value doesn't show the just updated value.
>- if (this.selectionOpen) {
>+ if (this.selectionOpen &&
>+ (aEvent.keyCode == aEvent.DOM_VK_BACK_SPACE ||
>+ aEvent.keyCode >= aEvent.DOM_VK_DELETE &&
>+ aEvent.keyCode <= aEvent.DOM_VK_Z)) {
Does this work in all cases? If yes, at least update the comment.
And fix alignment of second and third aEvent to be the same as first.
>
>-html|*:root html|input.-moz-xforms-select1-input:focus {
>- border: 1px dotted black;
>+html|*:root select1:not([selection="open"]) html|input.-moz-xforms-select1-input {
>+ cursor: default;
> }
Why you want to remove that border?
FF2 html:select does have focus ring.
Maybe r+, if I get reason for that CSS change.
|
|
Assignee | |
Comment 8•18 years ago
|
||
(In reply to comment #7)
> (From update of attachment 234675 [details] [diff] [review] [edit])
>
> > // ..other key events are handled in keyUp, because otherwise
> > // this.inputField.value doesn't show the just updated value.
> >- if (this.selectionOpen) {
> >+ if (this.selectionOpen &&
> >+ (aEvent.keyCode == aEvent.DOM_VK_BACK_SPACE ||
> >+ aEvent.keyCode >= aEvent.DOM_VK_DELETE &&
> >+ aEvent.keyCode <= aEvent.DOM_VK_Z)) {
>
> Does this work in all cases? If yes, at least update the comment.
> And fix alignment of second and third aEvent to be the same as first.
I guess, yes :). It handels all cases I know about.
> Why you want to remove that border?
> FF2 html:select does have focus ring.
>
I removed it since html:select hasn't such border at least in windows. I always thinks why that border is needed?
|
|
Assignee | |
Comment 9•18 years ago
|
||
I removed style changes and I use now input event instead keypress.
Attachment #234675 -
Attachment is obsolete: true
Attachment #234796 -
Flags: review?(Olli.Pettay)
Attachment #234675 -
Flags: review?(Olli.Pettay)
|
|
||
Updated•18 years ago
|
Attachment #234796 -
Flags: review?(Olli.Pettay) → review+
|
|
Assignee | |
Updated•18 years ago
|
Attachment #234796 -
Flags: review?(aaronr)
Attachment #234796 -
Flags: review?(aaronr) → review+
|
||
Comment 10•18 years ago
|
||
checked into trunk for surkov
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
|
|
||
Comment 12•18 years ago
|
||
checked into 1.8 branch on 2006/11/21
Keywords: fixed1.8.1.1
Whiteboard: xf-to-branch
|
||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•