Bug 10289 – Arrow keys scroll inconsistently

Bug 10289 - (int-171320) Arrow keys scroll inconsistently

(int-171320)
Summary:	Arrow keys scroll inconsistently

Status:	NEW

Product:	Browser
Component:	User interface
Version:	5.0:(20.2010.36-2)
Platform:	All Maemo

Importance:	Unspecified minor with 10 votes (vote)
Target Milestone:	---
Assigned To:	unassigned
QA Contact:	browser-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2010-05-26 06:54 UTC by Ryan Abel
Modified:	2010-10-28 00:47 UTC (History)
CC List:	5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description Ryan Abel (reporter) maemo.org

2010-05-26 06:54:34 UTC

SOFTWARE VERSION:
10.2010.19-1

EXACT STEPS LEADING TO PROBLEM: 

1. Open browser, load a web page that's at least 2 page long.
2. Open keyboard.
3. Begin scrolling with arrow keys (as if you were reading--short bursts).

EXPECTED OUTCOME:
Arrow keys scroll smoothly and predictably.

ACTUAL OUTCOME:
Arrow keys tend to scroll in fits and bursts, and often stick.

REPRODUCIBILITY:
Most of the time when I'm scrolling.

OTHER COMMENTS:
It makes it rather difficult to scroll effectively (and non-frustratingly) with
the arrow keys when you can never predict exactly how far it will scroll.
Having the ability to turn off smooth scrolling for keyboard scrolling would be
an acceptable fix if input cannot be improved.

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US)
AppleWebKit/531.9+(KHTML, like Gecko, Safari/528.16) OmniWeb/v622.10.0

Comment 1 Jonathan Mikhail 2010-05-28 21:20:50 UTC

OTHER COMMENTS:
I am encountering the same issue as Ryan, although after some experimentation,
I do believe I have determined the problem. It should be noted that this is a
new bug introduced with PR1.2, as previous firmwares did not exhibit this
behavior.

SOFTWARE VERSION:
10.2010.19-1.002

STEPS TO REPRODUCE THE PROBLEM:
1. Start internal web browser.
2. Open any page which requires scrolling. Length and content are irrelevant.
3. Begin any intensive activity that will peg the CPU at 100%. This can be
starting a YouTube video within the page, or even starting another application
on the device.
4. Scroll up or down using the arrow keys.

EXPECTED OUTCOME:
Scrolling ceases as the arrow key is released.

ACTUAL OUTCOME:
Scrolling will continue until the CPU drops below 100%, or the top or bottom of
the page is reached.

REPRODUCIBILITY:
Always.

Comment 2 Ryan Abel (reporter) maemo.org

2010-05-29 02:38:32 UTC

(In reply to comment #1)
> OTHER COMMENTS:
> I am encountering the same issue as Ryan, although after some experimentation,
> I do believe I have determined the problem.
>

Yeah, I agree with the findings. Which means it's probably not a browser bug,
but an X or kernel one. Hopefully someone more knowledgeable than me can weigh
in here.

Comment 3 Jonathan Mikhail 2010-05-31 16:17:09 UTC

(In reply to comment #2)
> 
> Yeah, I agree with the findings. Which means it's probably not a browser bug,
> but an X or kernel one. Hopefully someone more knowledgeable than me can weigh
> in here.
> 

Yeah, although this is the only application I've noted that's exhibiting this
problem.

It should also be noted that the only way to stop a "runaway scroll" seems to
be to tap on the screen.

Comment 4 Ryan Abel (reporter) maemo.org

2010-06-01 15:33:49 UTC

(In reply to comment #3)
> (In reply to comment #2)
> > 
> > Yeah, I agree with the findings. Which means it's probably not a browser bug,
> > but an X or kernel one. Hopefully someone more knowledgeable than me can weigh
> > in here.
> > 
> 
> Yeah, although this is the only application I've noted that's exhibiting this
> problem.
> 

True enough, but, sadly, many other scrollable areas don't allow arrow input
for some reason.

> It should also be noted that the only way to stop a "runaway scroll" seems to
> be to tap on the screen.
> 

Pressing the locked button again helps here, so maybe it's missing the key
release event. . . .

Comment 5 James 2010-06-09 17:45:45 UTC

I also have this problem, although it's not as bad now I've removed Adblock+. 

It's very easy to reproduce while a large page is loading (such as a long
reddit comment thread..). Press the down button while the page is loading,
until the browser responds (You may have to press the key several times for it
to work, I don't know if this should be submittedd as another bug, since that
behaviour is wrong as well) and the page will start scrolling down, but not
stop until it reaches the bottom of them page.

Comment 6 John Veness 2010-10-28 00:37:47 UTC

This bug is still present in 20.2010.36-2 (PR1.3) - please can someone change
the version field? (I tried myself but it wouldn't let me).

My example test case is as follows:
1. Quit all apps (not that I think we should have to, but just to be fair)
2. Run Web
3. Visit http://www.metro.co.uk/tech/games
4. Wait for page to load completely (not that I think we should have to, but
just to be fair)
5. Press hardware keyboard down arrow a few times, for different lengths of
time

Previously in PR1.1.1 keyboard scrolling was predictable and smooth on this
page, even while the page was loading and with File Manager and Notes apps
running in the background. Now with PR1.3 (I skipped PR1.2) with no background
apps and the page fully loaded, often the keypresses don't seem to be picked up
at all, or it will "run away" and keep scrolling down after releasing the key.

Comment 7 Jonathan Mikhail 2010-10-28 00:47:28 UTC

I, too, have been trying to perform some unofficial testing since upgrading to
20.2010.36-2.

Yes, I can confirm that this bug is still present. However, for reasons unknown
to me, it does appear to have improved slightly. That is, whereas it used to
scroll continuously to the top or bottom of the page, it will now only go an
arbitrarily number of pages (usually 1-3) before stopping.