Closed Bug 211846 Opened 21 years ago Closed 21 years ago

Alt-Down not working consistently with combo boxes

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: timwi, Assigned: aaronlev)

Details

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 WebWasher 3.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 WebWasher 3.2 The keyboard shortcut Alt-Down is usually used in Windows to open (pop up) a drop-down list. This does not seem to work in Mozilla. Reproducible: Always Steps to Reproduce: 1. Find webpage with drop-down field (e.g. http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser) 2. Keep pressing Tab until drop-down field has focus 3. Press Alt-Down Actual Results: Nothing Expected Results: Should open drop-down list
Worksforme in build 2003070408 on Mac OS X 10.2.6 (using option-down instead of alt-down ofcourse). See also bug 120456 and bug 205942.
Tested a little more and it seems to work for some drop-down lists. For me, it doesn't work with the following drop-down lists: 1) The "Component" drop-down on show_bug.cgi. 2) The boolean charts on query.cgi. 3) All the drop-downs on enter_bug.cgi. Of course, this may be a duplicate of Bug 205942, I'll add a comment to it.
Resummarizing and confirming. This is really strange and intermittent on the bugzilla Components example. I wonder why it's not working as well as F4. Another problem is that when Alt+Down does work the dropdown is displayed, it hides the combobox textfield and button by displaying on top of them instead of underneath. If you click or press F4 this does not happen. John, any thoughts why this might have regressed?
Assignee: aaronl → jkeiser
Severity: minor → normal
Summary: Alt-Down should open drop-down lists → Alt-Down not working consistently with combo boxes
Dup of 110801?
OK, so I just quickly tried out the Bugzilla query page on my linux build and some <select> I could drop down with either alt+down or f4, and some I couldn't drop at all, and the effect appeared to depend on the position of the <select>?
Actually it looks like a focus issue - focusing another window and back to the <select> and it starts working, until I tab or shift tab again.
This appears due to some #ifdef's rods added in a checkin for several bug fixes: FIX_FOR_BUG_62425 is not defined, so this code no longer operates. 3269 3270 keyEvent->GetAltKey(&isAlt); 3271 if (isAlt) { 3272 rods 1.172 #ifdef FIX_FOR_BUG_62425 3273 jkeiser 1.279 if (code == nsIDOMKeyEvent::DOM_VK_UP || code == nsIDOMKeyEvent::DOM_VK_DOWN) { 3274 if (IsInDropDownMode() == PR_TRUE) { 3275 PRBool isDroppedDown; 3276 mComboboxFrame->IsDroppedDown(&isDroppedDown); 3277 mComboboxFrame->ShowDropDown(!isDroppedDown); 3278 aKeyEvent->PreventDefault(); 3279 3280 nsCOMPtr<nsIDOMNSEvent> nsevent(do_QueryInterface(aKeyEvent)); 3281 3282 if (nsevent) { 3283 nsevent->PreventCapture(); 3284 nsevent->PreventBubble(); 3285 rods 1.172 } 3286 } 3287 jkeiser 1.279 } 3288 rods 1.172 #endif 3289 jkeiser 1.279 return NS_OK; I can't find any reason for it in any of the bugs mentioned with the checkin comment: 1.172 <rods@netscape.com> 20 Dec 2000 07:15 53259 - min-width and max-width not supported on form control 53457 - multiple items can be selected in select size=1 or in single select listbox 50376 - Cannot select with DOM option on dynamically created SELECT element 62442 - Incorrect extended selection behavior in listboxes First big change is getting rid of local variables for border and padding and use the ones in the reflow state Changed "IsInDropDownMode() == PR_TRUE && mComboboxFrame" to "IsInDropDownMode() == PR_TRUE" Fix for regression from changing of how key events work (no bug assigned), this fix enabled the user to hit 'f' or 'F' and get to the first item that start with 'f' or 'F' r=kmcclusk sr=buste
Assignee: jkeiser → aaronl
Taking
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #127163 - Flags: review?(rods)
Comment on attachment 127259 [details] [diff] [review] Same fix, but also gets rid of unnecessary code in comboboxframe for doing the same thing, and no longer cancels bubbling or capturing Neil, I tested without any code to handle this in combobox frame and it works. Rods, still looking for input why the code in listboxframe was #ifdef'd out
Attachment #127259 - Flags: review?(jkeiser)
Attachment #127259 - Flags: superreview?(bzbarsky)
Comment on attachment 127259 [details] [diff] [review] Same fix, but also gets rid of unnecessary code in comboboxframe for doing the same thing, and no longer cancels bubbling or capturing sr=me assuming you do: + if (IsInDropDownMode()) { instead of comparing the return value of that to PR_TRUE.
Attachment #127259 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 127259 [details] [diff] [review] Same fix, but also gets rid of unnecessary code in comboboxframe for doing the same thing, and no longer cancels bubbling or capturing I like this better than the naked resurrection of the ifdefs.
Attachment #127259 - Flags: review+
checked in
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Attachment #127163 - Flags: review?(rods)
Attachment #127259 - Flags: review?(jkeiser)
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: