When a name is entered into the Facebook search, normally in Safari, you can use the arrows to scroll through the list of names. With Webkit, you cannot. Thanks guys...
I'm not sure how to reproduce this. I entered a search for "John" at Facebook start page, and was forwarded to <http://www.facebook.com/srch.php?nm=john>. Up and down arrows scroll this results page just fine.
I believe Keaton is talking about the "autocomplete" list that Facebook shows beneath the search field as you type. The list shows a list of friends whose names match the characters you've typed so far. This might only appear if you're logged into a Facebook account, however.
Confirmed; the autocomplete list only shows up on a logged in account, as it is autocompleting from that account's friends.
I'm seeing similar functionality in the Gmail "To" field. Autocomplete suggestions are displayed, but the arrow keys don't change the selected option.
I can confirm this problem in the newest nighly build.
Depending on many confirmations I've changed status of the bug to NEW. However standalone minimal test case is still needed.
<rdar://problem/5754272>
its likely that the site is listening for keypress events, which we don't send anymore for arrow keys (a change we made to match IE).
I confirm the issue comes from the keypress event which don't fire anymore for arrow keys - and this is causing the problem. Here is another example (it uses jquery) : http://www.filmdeculte.com/photo/5/Rachel-Nichols-10234.html#slide Firefox fire keypress for arrows, but as you said IE 6 and 7 don't (and now webkit ...). Why was that behaviour changed, was it causing issues ? Matching IE is not a reason if it's not an issue or not against standards IMHO ;) Many tech-aware sites use firefox features to allow richer user experience like this one.
(In reply to comment #9) > Why was that behaviour changed, was it causing issues ? Yes. It's clear that we are having compatibility issues either way, but our previous behavior was translating into bugs with international text input that were very hard to avoid without changing the whole model (and that we sometimes even shared with Firefox). In short, a keydown event corresponds to a low-level event that is not yet translated, and thus carries a virtual key code parameter, while keypress corresponds to a high-level character event, and carries a character code. There are no character codes for arrow keys, so we simply had to get rid of keypress events for those (previously, they carried semi-bogus codes in WebKit that weren't compatible with any other browser). > Many tech-aware sites use firefox features to allow richer user experience like > this one. While it is obvious that we fixed some compatibility bugs, and obtained new ones, I think that IE's model that we now match is perfectly suitable for developing a rich UI. If you have examples for which it is inferior, I'd be very interested to hear about those!
Thanks for the very clear / complete explanation ! A poste to Surfin’ Safari would be a good idea. Seems I was missing many informations ;)
The arrow keys now work in the latest nightly.
(In reply to comment #12) > The arrow keys now work in the latest nightly. > Confirmed also in stock Safari 3.1. So the code on facebook.com was fixed.