page up and page down do not work when a pop-up menu has just been used.

NEW
Unassigned

Status

Camino Graveyard
HTML Form Controls
P2
major
15 years ago
8 years ago

People

(Reporter: Brad Kemper, Unassigned)

Tracking

Details

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030113 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030113 Chimera/0.6+

Clicking on a pop-up menu makes it hog all the keyboard presses, even though
there is nothing to indicate that it is selected. This prevents the page up and
page down keys from scrolling the page up and down. This should be fixed.

On a slighly more esoteric note, it should not even be intercepting the arrow
keys to change the selcted menu item. I do not have full keyboard access on, so
chnging a pop-up menu should not change the selection. If I am in a text box,
the cursor should remain there for further typing, and if not, arrrow keys and
paege up, page down, home, and end should continue to work at moving the page up
and down. In any event, it should not just beep at me like it can't figure out
what I want.

Reproducible: Always

Steps to Reproduce:
1.Click on a pop-up menu
2.Type "page up" or "page down"


Actual Results:  
the alert sound plays (beep or whatever)

Expected Results:  
page should move up or down.

Comment 1

15 years ago
Confirmed in 2003012004. PageUp/PageDown will jump to the first/last items in
the popup. Should be passed to the page instead.
Status: UNCONFIRMED → NEW
Ever confirmed: true
still true with 2003082402.

Comment 3

14 years ago
This has been frustrating me on http://slashdot.org - If one hits a moderation
pull down list to moderate a Slashdot post, select a moderation level, then hit
page down to read more content, the prior pull-down list is still selected and
the page down key inadvertently scrolls to the end of the pull down list.  This
yields unexpected moderation input when the "Moderate" button is pressed.  Build
2004092308 (v0.8+).

BTW, I had mod points for the Slashdot article referencing the Pink interview ;)

Comment 4

13 years ago
Focus issues?
Priority: -- → P2
Target Milestone: --- → Camino1.0
(In reply to comment #4)
> Focus issues?

Is this essentially the same focus issue as in bug 294882?  (See bug 294882
comment 4)

Comment 6

13 years ago
(In reply to comment #5)
> (In reply to comment #4)
> > Focus issues?
> 
> Is this essentially the same focus issue as in bug 294882?  (See bug 294882
> comment 4)

I think it's different. I think, here, focus is being grabbed by the gecko form
widget (that we don't use). Maybe some user-focus style in forms.css would fix this.
Assignee: bryner → sfraser_bugs
Simon, is this something you want to look at for 1.0? If it's just a forms.css change, it shouldn't be too hard to fix.

Comment 8

12 years ago
Not forms.css. Scarey focus stuff.
Target Milestone: Camino1.0 → Camino1.1
See also bug 294882 and bug 154226, which are different manifestations of our "hacky select implementation".
Is this getting cleaned up in the polishing of Cocoa widgets?
QA Contact: winnie → form.controls
Target Milestone: Camino1.1 → Camino1.2

Comment 11

11 years ago
Probably the correct behavior is that using the mouse on a control shouldn't focus it if the tab settings are such that it's not a focusable control. I suspect that makes this a core bug.
Assignee: sfraser_bugs → nobody
Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Fwiw, this issue still happens with the latest Minefield build (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a6pre) Gecko/20100619 Minefield/3.7a6pre)

--> core ?
Probably better to file a new bug on the regression for Firefox, and if it happens to fix this for us, then great; otherwise, we don't donate our bug for a fix that doesn't actually fix us.
Filed core bug 573411 for that issue (as far as I could test, it never worked correctly in Firefox).
You need to log in before you can comment on or make changes to this bug.