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.
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.
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 ;)
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)
(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.
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
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.