Closed Bug 363002 Opened 19 years ago Closed 19 years ago

rows skipped when going down in URL autocomplete list

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jaas, Assigned: jaas)

References

Details

(Keywords: dogfood, regression)

Attachments

(1 file, 2 obsolete files)

fix v3.0
1.65 KB, patch
mark
: review+
Details | Diff | Splinter Review
Regression from the fix for 355817... Open up Firefox and type something into the URL bar that gives a bunch of autocomplete options. Hit the down arrow and notice that it goes down 2 rows instead of just one at a time.
*** Bug 363181 has been marked as a duplicate of this bug. ***
Should we treat this as covering all the keyboard navigation problems (double up/down in trees, in Fx prefs and in Thunderbird, double scrolling with up/down arrows in content, page-up and page-down not working, arrow keys not working to move around in textinputs), or file them all separately?
*** Bug 363201 has been marked as a duplicate of this bug. ***
Pageup/pagedown not working correctly is totally a blocker -- can't switch tabs normally, can't read bugs, etc. Combined with the lack of arrow keys in textareas, this basically makes bugzilla unusable. This is _much_ worse than bug 355817 -- please back that out before the next nightly if you don't have a fix for this by then.
Blocks: 355817
Severity: normal → blocker
Keywords: dogfood
Firefox seems to be handling arrow keypresses both on keydown and on keyup.
fix coming soon
Attached patch fix v1.0 (obsolete) — — Splinter Review
For some reason certain keys (at least arrow keys and page up/down) send an event for key up *and* down. We should just handle the key down command events.
Comment on attachment 248213 [details] [diff] [review] fix v1.0 r=me, with a comment mentioning why it's necessary
Attachment #248213 - Flags: review+
r=me. looks good, keyup is pretty silly here.
*** Bug 363412 has been marked as a duplicate of this bug. ***
Comment on attachment 248213 [details] [diff] [review] fix v1.0 r=me for real this time.
Comment on attachment 248213 [details] [diff] [review] fix v1.0 r=me for real this time.
landed on trunk
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment on attachment 248213 [details] [diff] [review] fix v1.0 +r for real for real.
Comment on attachment 248213 [details] [diff] [review] fix v1.0 r=me, really.
Attachment #248213 - Flags: review+
Still not quite right. Arrow keys now don't work at all in textareas.
Yeah, I see that now. It doesn't happen in the URL bar, where I tested before. I think we might have to specifically intercept arrow key commands and page up/down and handle them specially.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Look. This bug is making it completely impossible to use the build for daily work -- for example, doing patch reviews in not really feasible if key nav doesn't work. Please back out bug 355817 if you don't have a fix for this by tonight, ok? I'm a little confused about why this didn't happen two days ago...
Yeah, I'd have backed it out last night but I thought this fixed it and then it was too late. Will back out today if it isn't fixed.
There's another problem with key nav -- if I click on a combobox, I can't use the up/down arrow keys to select an entry. For example, try setting "blocking1.9?" on this bug with the keyboard -- can't be done. Should we be filing separate bugs on these issues?
Attached patch fix v2.0 (obsolete) — — Splinter Review
No, that is the same issue. The problem here is what Mac OS X considers a potential keyboard command, and it not only considers arrow keys to be that but it also sends events differently for them than it does other things that it thinks are command events. This patch fixes the problems for me, but I'm going to test it and think about it for a little longer before landing it.
Attachment #248213 - Attachment is obsolete: true
Attached patch fix v3.0 — — Splinter Review
Another approach, probably better. We have to intercept key commands with performKeyEvent in order to stop the menu system from rejecting things we want to pass into gecko. The problem is that we get some things coming into performKeyEvent that we don't want to handle as a key press - like arrow keys and page up/down. I was thinking about how we might tell things like that apart from the commands we want to handle, and from the information available from NSEvent objects it looks like our only hope is to look at modifier flags. So I profiled the flags that are being set for different keys and it turned out to be fruitful.
Attachment #248286 - Attachment is obsolete: true
Attachment #248296 - Flags: review?(mark)
I accidentally typed performKeyEvent when I meant to type performKeyEquivalent in comment #22. Also, I should mention that v3.0 also fixes home and end keys, some others too probably.
Comment on attachment 248296 [details] [diff] [review] fix v3.0 I guess this is better than plucking out the keys one by one as in v2.
Attachment #248296 - Flags: review?(mark) → review+
landed to make the next nightly for testing, if this has any problems left then our best bet is to get some nightly testing
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
*** Bug 363474 has been marked as a duplicate of this bug. ***
I just came home and minefield was waiting to confirm restart for update... and now, after the update, page up / down is working fine... (coming from duplicate bug 363474)
*** Bug 363685 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: