maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Smooth scrolling not active using arrow keys until current page tapped|
|Product:||[Maemo Official Applications] Browser||Reporter:||Donn Morrison <donn.morrison>|
|Component:||User interface||Assignee:||Nagineni Sudarsana Babu <naginenis>|
|Status:||VERIFIED FIXED||QA Contact:||browser-bugs|
|Priority:||Low||CC:||andre_klapper, john.maemo, maemo, tim|
STEPS TO REPRODUCE THE PROBLEM: 1. Open browser from application list 2. Tap default Google search shortcut 3. Enter search terms (e.g. "maemo 5") into Google 4. Press enter or click search button 5. Scroll results page using arrow keys EXPECTED OUTCOME: Smooth scrolling should be observed. ACTUAL OUTCOME: Discrete scrolling is observed until web page is tapped in blank area using finger or stylus. REPRODUCIBILITY: always OTHER COMMENTS: Once the page is tapped, smooth scrolling works with the arrow keys. User-Agent: Mozilla/5.0 (X11; U; Linux armv7l; fr-FR; rv:1.9.2a1pre) Gecko/20090928 Firefox/3.5 Maemo Browser 18.104.22.168 RX-51 N900
It seems that changing between fullscreen and non-fullscreen mode is enough to get smooth scrolling working (as does tapping in a blank area on the page).
I notice that while the "discrete scrolling" is happening with the arrow keys, there is no scrollbar visible. Tapping the screen which activates the smooth scrolling also makes the scrollbar appear.
Thanks for reporting this. In version 44-1 tapping the arrow-down keyboard key will display the location bar in the browser. I think that makes sense and is a feature that would collide, hence this is a WONTFIX.
(In reply to comment #3) > In version 44-1 tapping the arrow-down keyboard key will display the location > bar in the browser. I think that makes sense and is a feature that would > collide, hence this is a WONTFIX. I don't see why this is needed, since any alphabetic input will also do that. Does that mean no arrow key scrolling at all after 44-1, or will it work after the first press? I'm being optimistic and assuming the latter, in which case this could still be fixed. Otherwise, why not use Ctrl-L (finally fixed at around the same time according to bug 3298) to display the location bar for consistency with non-fullscreen mode?
(In reply to comment #3) > Thanks for reporting this. > > In version 44-1 tapping the arrow-down keyboard key will display the location > bar in the browser. I think that makes sense and is a feature that would > collide, hence this is a WONTFIX. > WHOA! Backup there. There's NO MORE arrow scrolling after 44-1?
(In reply to comment #5) > WHOA! Backup there. There's NO MORE arrow scrolling after 44-1? WHOA. No. I just described the situation in 44-1. It's of course different in later releases. In 46-16, arrow scrolling works for me, the location bar does not open anymore, and starting the browser, entering an URL, (which automatically goes to a new fullscreen window), loading it, and using the arrow down key at least works fine for me. Might of course break next week again. Feel free to change the resolution to FIXED or something(TM).
(In reply to comment #6) > In 46-16, arrow scrolling works for me That's good news of course, but for the purposes of this bug is the scrolling "smooth" or "discrete" (as per comment 0)? In 42-11 it's exactly as reported.
(In reply to comment #7) > That's good news of course, but for the purposes of this bug is the scrolling > "smooth" or "discrete" (as per comment 0)? In 42-11 it's exactly as reported. It's quite smooth. There's a little bit of lag, but it's hardly visible.
FIXED it is then :-)
Oops, reopening. It's _better_, but certainly not fixed. It still see it every so often.
I see. :)
(Fixed in internal 10.2010.06-13, waiting for verification before setting status)
This has been fixed in the internal build version 10.2010.06-13 (Note: 2009/2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
Confirming as fixed in PR1.2.