maemo.org Bugzilla – Bug 1791
link navigation should be triggered by key-up not key-down and only if scrolling isn't triggered
Last modified: 2007-10-27 20:47:55 UTC
You need to log in before you can comment on or make changes to this bug.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: Mozilla/5.0 (11; U Linux armv6; en-US; rv:1.9a6pre) Gecko/20070810 Firefox3.0a1 Tablet browser_0.1.16 RX-34_2007.26-8 On the N800, when pressing the navigation buttons to scroll down on a Web page, after any web page has finished loading, the first input field on the page will be focused, instead of the page starting to scroll. If you press the navigation button for a second time, the browser will start scrolling as expected. In case the page already has focus on a input field after it is loaded (like yahoo or google), the page will start scrolling. Reproducible: Always Steps to Reproduce: 1. Go to www.economist.com. 2. Wait until page has finished loading. 3. Press the navigation button on the left side of the N800 and keep it pressed down. Actual Results: The focus will jump to the first input field and not scroll. Expected Results: Keeping the navigation button pressed, should always scroll up or down from the position of the page at that moment. It would be more usable, if it worked exactly like Opera version of the browser. This bug is preventing me from using Moz as my default browser. My personal killer app on the N800 is Bloglines mobile (and I would bet for others too). The input field is located at the bottom of the page. One hand navigation on the go is hard when the page jumps to the bottom on the first touch of the navigation button.
Some precision on this bug : in fact, a constant press on dpad is first handled as a press event (causing the next hyperlink or entry field to be selected) and then, scrolling is done. For instance, for url https://bugs.maemo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&component=Browser+%28Mozilla+Engine%29&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= if you press/hold down button, you'll notice next bug id is selected before scrolling starts. This is sometimes preventing scrolling by first moving view to another part of the page you were trying to read.
are we supposed to be using keyup instead of keydown (to handle short presses)?
Yes, key release should be used for short press, instead of key press.
OK. Tested w/ Opera on 770. Indeed, the behavior should be to trigger navigation on release and only if it isn't replaced. the simplest change is swapping up/down here: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/extensions/spatialnavigation/src/nsSpatialNavigation.cpp&rev=1.17&mark=72,84,86-315#71 (it's better to refactor the code so that up or down calls a function instead, my js based impl did that.) I don't know offhand where the magic is that decides whether to scroll or do link navigation. That's probably somewhere else.
Fixed Sending patches/series.gtk2 Adding patches/snav/BUG50934.spatial_scrolling.diff Transmitting file data .. Committed revision 697.