758970 - Real bad scrolling on Archos 70 internet tablet

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Jan Manthay]

Attachment: logfile

The Divice:
Is an Archos 70 Internet Tablet
http://www.archos.com/products/ta/archos_70it/index.html?country=us&lang=en

Resolution is 800x480, no hard buttons, but about 30px on the right side used as button area.

Android Version is 2.2.1, WITHOUT Google Play Store.

CPU is at 1 GHz.

RAM is 256 MB RAM , free RAM is about 140MB, during use of Aurora about 60MB are still free.
So RAM is a bitunder the specs, but I dont think that is the problem here.

The Problem:
Scrolling is a pain. It stutters a bit, but not more than on the XUL Version, so thats not a big deal.
But what's worse is that I cant scroll to the place I want, because the scrolling act does not stop when I release my finger from the sreen. It scrolls always further, sometimes only a little, sometimes more, and sometimes even till the end of the page. And that in microseconds, release finger, bang, content is (sometimes) out of the screen.
It does not matter how much I scroll with my finger, only a few mm can cause a real long "afterscroll", while a longer way may only affect in a short "afterscroll". It is absolute random. The area I use for scrolling has no affect, right or left side, lower or upper part, does not matter.

So it is very hard to keep the content I want on the place I want.
This is a problem for a longer time now, actually affects Aurora 14 (and probably Nightly 15, at least it does last time I checked)

I add a Logcat report, where I did some scrolling.

Comment 1

[Aaron Train [:aaronmt]]

This might be fixed with bug 749568. Kats?

Comment 2

[Kartikaya Gupta [:kats]]

The way you're describing it sounds like normal flinging behaviour.

(In reply to Jan Manthay from comment #0)
> But what's worse is that I cant scroll to the place I want, because the
> scrolling act does not stop when I release my finger from the sreen.

Yes, if you lift your finger from the screen right after dragging your finger, the scroll will continue depending on how fast you were dragging before you lifted your finger.

> It
> scrolls always further, sometimes only a little, sometimes more, and
> sometimes even till the end of the page.

Yes, this is based on the velocity your finger had when you lifted it.

> And that in microseconds, release
> finger, bang, content is (sometimes) out of the screen.
> It does not matter how much I scroll with my finger, only a few mm can cause
> a real long "afterscroll", while a longer way may only affect in a short
> "afterscroll".

Sure, it depends how fast you move your finger; if you move it really fast over a few mm it will result in a large fling velocity; if you move it slowly over a larger distance it will result in a smaller fling velocity.

I'm sure you are probably seeing some strange behaviour, but the way you describe it does not really help me diagnose the problem because what you're describing could just be normal flinging behaviour. There's also nothing abnormal in the log you attached.

If what you're seeing is not normal flinging behaviour, then the closest bug to this that I can think of is bug 749384, but that should be fixed. It would be helpful to see what kind of touch events you're getting from the hardware to see if they make sense. If you have some time, please download the build from [1] and please grab the logcat from that build while reproducing the bad behaviour. It has some extra logging that will help me diagnose the error. The build in that APK will show up as "Fennec kats" on your device, and should be completely independent of any other firefox build you have.

[1] https://people.mozilla.com/~kgupta/tmp/logtouchevents.apk

Comment 3

[Jan Manthay]

Attachment: "Fennec kats" logfile

(In reply to Kartikaya Gupta (:kats) from comment #2)

> Yes, if you lift your finger from the screen right after dragging your
> finger, the scroll will continue depending on how fast you were dragging
> before you lifted your finger.

I see now that my report was not clear enough, I know the normal behavior, and this does more or less work as expected.

What I meant was this:
- Touch the screen
- Scroll about 1-2 cm up or down, so that the content is in the place you want
- STOP your finger
- Release your finger.

What should happen: 
The screen should stay in this position. It does so on XUL, and it does so with Native on my Sony smartphone. It does so on every other App, like the stockbrowser, logcat, or in the android preferences. There is always a very little "afterscroll even there, but not more than 3-6 px.

What happens:
It does not stay in this position, instead there is a random amount of scrolling, sometimes a real big on.

test apk was installed, here comes the log.

Comment 4

[Kartikaya Gupta [:kats]]

Thanks! The log looks like it has some useful information. It looks like the hardware generates a touch-move event right before you lift your finger of about 5 pixels and that's what causes us to kick off a fling.

For example in this set of touch events:

303869279 MotionEvent{454c9608 action=2 x=626.95386 y=118.76192 
303869294 MotionEvent{454c9608 action=2 x=626.95386 y=118.76192 
303869310 MotionEvent{454c9608 action=2 x=626.95386 y=118.76192 
303869327 MotionEvent{454c9608 action=2 x=628.1545 y=113.8958 
303869331 MotionEvent{454c9608 action=1 x=628.1545 y=113.8958

You can see the first three move events all have the same x and y coordinates (626.95, 118.76) and then the fourth move event which happens just before the touch-up event is off by 1.2 pixels on the x coordinate and 4.9 pixels on the y-coordinate. Similar behaviour happens on the other two touch-up events in the log.

I guess that our physics code doesn't deal with this input as well as the XUL browser or apps on your phone; we'll have to look at how it can be tuned to filter out flings like this without affecting other devices.

Comment 5

[Jan Manthay]

This seems to be fixed in recent nightlys.
I cant say the exact date since when, but its ok now.

Comment 6

[Kartikaya Gupta [:kats]]

That's good to hear. I can't think of any recent change that might have fixed this.