try to select the first and the third entry in that example and you'll see... it should toggle the selected with <space>, but doesn't
forgot to say: tested in 200202821 and 1.0/Debian - both broken. Got report, that it works in 0.9.9
On WinXP, Ctrl+Down followed by Ctrl+Space works in 0.9.9 but not in 1.0.0 or a ~1.1b nightly from 07/27. Sending to jkeiser, who added the Ctrl+Up, Ctrl+Down, and Ctrl+Space shortcuts in bug 40983 (before 0.9.9). CC rods, who might have broken this with his patch to bug 64165 (between 0.9.9 and 1.0). Bug 64165 added a focus outline around the selected item in an HTML select.
Assignee: aaronl → jkeiser
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: access, regression
OS: Linux → All
Hardware: PC → All
Summary: no way to multiselect in <select> → no way to multiselect using keyboard
Confirming: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020721 *AND* Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722
Funny thing, focus ring not showing up either on multiselects.
chg summary to differentiate from bug 97434
Summary: no way to multiselect using keyboard → no way to multiselect using keyboard in list box
Created attachment 106990 [details] [diff] [review] enable SPACE/Ctrl+SPACE to select list item Now we are using charCode instead of keyCode to store non-control key's code for keypress event, so checking the charCode would fix this regression.
Assignee: jkeiser → kyle.yuan
akkana: could you clarify the difference between charCode and keyCode?
Comment on attachment 106990 [details] [diff] [review] enable SPACE/Ctrl+SPACE to select list item jkeiser said on IRC that this patch is good from coding point of view, but he needs akkana's confirmation on the usage of charCode/keyCode, so seek r=akkana.
Attachment #106990 - Flags: review?(jkeiser) → review?(akkana)
Comment on attachment 106990 [details] [diff] [review] enable SPACE/Ctrl+SPACE to select list item I agree with using char code instead of key code to check for space; but DOM_VK_SPACE is a key code. Char codes are printable characters, e.g. ' '. It's only coincidence that DOM_VK_SPACE happens to be the same as ' ', but you should test for the character and not for the DOM_VK code when you're testing charcode. Otherwise the patch looks fine. (I didn't test that -- the test url in the bug doesn't seem to be there. What's a good test case?)
Attachment #106990 - Flags: review?(akkana) → review-
Created attachment 107099 [details] [diff] [review] use ' ' instead of DOM_VK_SPACE BTW, you can use the CC list on this page for testing.
Attachment #106990 - Attachment is obsolete: true
The code looks fine (including the charcode == ' ' part), but I still can't figure out how to test it. I'm trying to select items in the cc list using the spacebar, with and without shift and ctrl, and up and down arrows; but as soon as I move up or down with the arrow keys, I lose any selection I've made, and the spacebar seems to make no difference when I'm on an item. Ah -- if I shift-arrow instead of just arrowing, then I can move the selection without unselecting the item I'm on (it doesn't seem to matter whether I've hit the spacebar while on that item first, though) and ctrl-space on a new item will add it to the selection. Is that all that this is intended to do? I also tried shift-space, thinking that it would select everything between the currently selected item and the new one, but it didn't do that. (Hmm, shift-click doesn't do that either. I guess I'm still in a NS4/text selection mindset there.) I don't want to block this just because I don't understand the feature -- the code does look better than what was there before -- but could you give me a quick explanation of what to do to test this, what it did before and what it's expected to do?
Comment on attachment 107099 [details] [diff] [review] use ' ' instead of DOM_VK_SPACE I'll go ahead and mark it r=akkana, because I did get the ctrl-arrow/ctrl-space thing to work.
Attachment #107099 - Flags: review?(akkana) → review+
There are the keyboard navigation scheme for listbox of Windows and GTK application. I've copied it from http://developer.gnome.org/projects/gap/keynav/gtk_lists.html Windows: Spacebar = make a selection. Deselects previous selection only in extended- selection listbox, not in multiple selection listbox. Ctrl+Spacebar = discontiguous extension, doesn't affect previous selection Shift+spacebar = contiguous selection, extends selection from previous selection point Shift+down = extend selection down Shift+up = extend selection up Shift+home = extend selection to beginning of list Shift+end = extend selection to end of list Shift+page down = extend selection down one view Shift+page up = extend selection up one view GTK: Ctrl+A , Ctrl+/= Select all Shift+Ctrl+A, Ctrl+\ = Deselect all Spacebar = make a selection, deselects previous selection Ctrl+Spacebar = discontiguous extension, doesn't affect previous selection Shift+spacebar = contiguous selection, extends selection from previous selection point Shift+down = extend selection down Shift+up = extend selection up Shift+home = extend selection to beginning of list Ctrl+home = focus and add first item in list to discontiguous selection Shift+end = extend selection to end of list Ctrl+End = focus and add last item in list to discontigous selection Shift+page down = extend selection down one view Shift+page up = extend selection up one view Ctrl+PgUp/PgDn = select and move focus to top/bottom of view, then top/bottom of previous/next view on subsequent press Printable character string = select next visible item in list starting with that string Printable character = select next visible item in list starting with that character Now, we've implemented all of the GTK proposed, except the select/deselect all.
sorry, above scheme is for listbox's *selection* only. My patch is aimed at the functionality of SPACE, Ctrl+SPACE and Shift+SPACE.
Shift+SPACE not doing what it supposed to do is because we can't determine what the previous selection point is. I suggest to file a new bug against this.
Attachment #107099 - Flags: superreview?(bryner) → superreview+
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
>Windows: >Shift+page down = extend selection down one view >Shift+page up = extend selection up one view Isn't that extend selection to end/beginning of view? Also, in windows multiselect (not extended) listbox, modifiers are ignored, all keys behaving as ctrl keys in extended listbox: space toggles, others move.
ctrl+space will multiple select (non-contiguously) fine on linux and win2k, but command+space fails to do so on mac. (cannot use ctrl+space on mac since that's reserved for bringing up the context menu.) was this fix intended to be for all platforms, or only win32 and unix? tested on rh8 and win2k using trunk commercial builds (2002.12.16.08), and mach-o mozilla trunk bits on mac os x 10.2.2.
It was intended for all platforms. Best file a new bug on it and CC me and Kyle.
Sorry for my ignorance of Mac stuff. Please file a new bug if cmd+space is a common key binding for discontiguous selection on mac. It won't be a difficult thing.
okay, i've filed bug 185904 for the mac issue. vrfy'ing this one...
Status: RESOLVED → VERIFIED
Should this be triggering if the user is typing text to scroll to? eg if I focus the "component" dropdown and type "Layout: F" it focuses "File Handling" which is _so_ not the expected or desired behavior...
You need to log in before you can comment on or make changes to this bug.