716776 - Scrolling is much slower than stock, xul fennec on Android

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: Toolbar, defect, P3)

Description

[Sam Tobin-Hochstadt [:samth]]

Flinging the page scrolls much less far than in the Android stock browser or XUL Fennec.

To reproduce, visit: http://crookedtimber.org/2011/12/16/solidarity-2/ and try to scroll to the bottom in as large flings as possible.  For XUL Fennec, this took 2 flings, for Android stock 3 flings, for Opera Mobile 3 flings, and for Native Fennec (Aurora) 13 flings.  

[See also bug 705092]

Comment 1

[Sam Tobin-Hochstadt [:samth]]

Just for reference, this is on an HTC Sensation with Android 2.3.1.

Comment 2

[Chris Lord [:cwiiis]]

Just to note that the HTC Flyer has some oddness with its motion events that means the acceleration gets scaled down - we have code to help counteract this, but it doesn't work very well. This could be true for other HTC hand-sets - especially as the Sensation hardware is very similar to the Flyer.

It'd be good to get UX comment on this, and for it to be tested on another phone (I know the Galaxy Nexus works fine, for example).

The problem with events could be fixed by:
- Tweaking current numbers (unlikely, the way I counteract it can negatively affect devices without the bug)
- Using a more complex smoothing algorithm (totally possible, I had a better one working before we switched to the Java compositor)
- Using the Android system gesture detector (this will make us consistent with other Android applications too, but the system detector is laggier than it needs to be)

I'm swaying (again) towards using the system detector, as I can envisage problems like this coming up again and we know that the system detector will definitely work (or if not, the entire system will be broken and user expectation oughtn't be for us to be any better).

Comment 3

[Patrick Walton (:pcwalton)]

(In reply to Chris Lord [:cwiiis] from comment #2)
> I'm swaying (again) towards using the system detector, as I can envisage
> problems like this coming up again and we know that the system detector will
> definitely work (or if not, the entire system will be broken and user
> expectation oughtn't be for us to be any better).

Note that the system detector is not the same as using the system fling physics -- the latter is probably not an option for us as it's tied to the Android scroll and list views.

Random, off-the-wall idea: Maybe we could use the ICS system detector?

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

The friction setting has got some complaints via SUMO and MTD. Maybe we need to ease it up a bit?

Comment 5

[Patrick Walton (:pcwalton)]

(In reply to Mark Finkle (:mfinkle) from comment #4)
> The friction setting has got some complaints via SUMO and MTD. Maybe we need
> to ease it up a bit?

This is very device specific, in my experience. It feels very different on the Droid X and the Droid RAZR, for example. For the complaints, we should be sure to get the device the users are using.

Comment 6

[Sam Tobin-Hochstadt [:samth]]

Following up, this got better for a while (ie, scrolling got noticeably faster), but within the last few weeks it's gotten very slow again.

Comment 7

[Sam Tobin-Hochstadt [:samth]]

This continues to be a big problem for me on the HTC Sensation. I tested with the latest Nightly, and it's still 13 flings to scroll the page I mentioned in the description to the bottom.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

On my Galaxy Nexus I'm able to scroll to the bottom of this page in ~5 flings, and ~2 on the stock browser. However, the scrolling is smooth and looks like our normal scrolling behaviour.

The reason this behaviour is different is because of font inflation. We render the page in a larger font so that it is more readable, and as a result the page is actually much longer (in pixels) than it is on stock browser. This is evident when you first load the pages - much less of the content is visible on Fennec than on the stock browser. I also verified this by setting the font.size.inflation.minTwips pref to 0 to disable font inflation. With font inflation disabled, I am able to scroll the entire page in ~2 flings, same as the stock browser. If anything, we scroll faster than the stock browser.

I'm going to mark this as INVALID because it seems to me that this is the desired behaviour given font inflation (which actually works perfectly on this page and makes it quite easily readable without zooming). Feel free to reopen or file a new bug if you feel that the trade-off between font inflation and scroll speed needs to be adjusted here.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Err, sorry. WONTFIX is a better resolution for now.

Comment 10

[Sam Tobin-Hochstadt [:samth]]

5 flings is totally fine, and the details of font inflation aren't the issue here.  The bug is that on the Sensation, it takes 13, which is really annoying both on very long pages like this, and on shorter pages.  On the Sensation, the experience of scrolling is totally different (ie, much slower) in Fennec than in any other app I use.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Ah, in that case, would you mind running the build at [1] and sending me the logcat output of your fling-as-fast-as-you-can on the page? The build is the latest mozilla-central code plus an extra line to log all the touch events we receive in fennec. With that I should be able to reproduce and diagnose the problem better. Note that the build will install as "Fennec kats" and will be independent of any existing fennec apps you have on your device. You can uninstall it after grabbing the log by running "adb uninstall org.mozilla.fennec_kats" (assuming you have the Android SDK installed and adb on your path).

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

Comment 12

[Sam Tobin-Hochstadt [:samth]]

Ok, I'll do that.  I may not be able to get to it for a little while, but I will.

Comment 13

[Chris Lord [:cwiiis]]

Just to add in some info, the HTC Sensation has a very similar build to the HTC Flyer, and thus likely has the same motion event bug - On release, you get two motion events before it with identical coordinates, which means that the last couple of motion events register as having zero velocity.

I added code ages ago to even this out slightly, but this code negatively affects other devices if you ramp it up too high. I've seen the official Google Music app suffer from the same problem, though the built in gesture object doesn't.

I think we should probably look what the Android code does for motion event smoothing, and perhaps a quick fix, we should just detect this situation/these devices and ignore those events.

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Oops, accidentally reset assignee.

Comment 15

[Chris Lord [:cwiiis]]

I don't actually have an HTC Sensation, and while the Flyer does have some odd behaviour pre-honeycomb, I can't reproduce this bug to that level...

I'm not sure what we want to do with this, do we know if anyone on the mobile team has an HTC Sensation?

Comment 16

[Frederik Niedernolte]

I also have this problem with Firefox Beta 20 and a Google Nexus 4.
Scrolling seems to be jumpy, too and different sites react differently in my opinion. 
is there a fix for this?

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Frederik: the "jumpy scrolling" may be bug 805479.

Comment 18

[Frederik Niedernolte]

Could be true, thanks. 
But also the scrolling speed seems to be slower than the stock browser. 
Any about:config settings to tweak?

Comment 19

[Kartikaya Gupta (email:[e-mail])]

There are some prefs you can tweak to reduce the friction, see https://wiki.mozilla.org/Mobile/Fennec/Android#Tweaking_UI_prefs - the ones you probably want are the first three on the list. Note that some students are also looking into implementing accelerated scrolling in bug 708765.

Comment 20

[Chris Lord [:cwiiis]]

I'm unassigning this - as far as I can tell, our scroll speeds are deliberate and this is a UX issue (or bug 708765).

Comment 21

[Sam Tobin-Hochstadt [:samth]]

I'm confused by your comment, Chris.  Do you mean that (a) this is a UX bug because the chosen values for scrolling speed cause scrolling slower than almost all other Android apps, or (b) UX has deliberately chosen to make scrolling slower than almost all other Andorid apps, and thus this isn't a bug at all?

Comment 22

[Chris Lord [:cwiiis]]

(In reply to Sam Tobin-Hochstadt [:samth] from comment #21)
> I'm confused by your comment, Chris.  Do you mean that (a) this is a UX bug
> because the chosen values for scrolling speed cause scrolling slower than
> almost all other Android apps, or (b) UX has deliberately chosen to make
> scrolling slower than almost all other Andorid apps, and thus this isn't a
> bug at all?

I mean (a). (b) is a question for UX, I suppose.

Comment 23

[Kartikaya Gupta (email:[e-mail])]

This is not actionable as I never got the data I asked for in comment 11 and we can't reproduce unexpectedly slow scrolling.

Comment 24

[Sam Tobin-Hochstadt [:samth]]

kats, I'm not sure what you mean. Are you saying that when you scroll a large web page in Chrome and Firefox on the same android device, they have the same max scroll speed? I've tested this on plenty of different devices and it's true on all of them.

Comment 25

[Kartikaya Gupta (email:[e-mail])]

What I mean is that I'm not sure what the problem is here. There's at least three different hypotheses in this bug:
(1) font inflation makes the page longer so obviously it takes more flings to get to the bottom (you claimed this is not the problem in comment 10).
(2) the hardware you're testing on is sending bad touch event data. to verify this I asked for data in comment 11 which you said you would provide in comment 12 but never did.
(3) the behavior is expected because that's what our friction settings are intended to do, and if you have a problem with them you can adjust them via the prefs linked to in comment 19.

None of these three options have any further actionable steps, so this bug is unactionable.

Comment 26

[Sam Tobin-Hochstadt [:samth]]

(1) is definitely not the case, identical length pages scroll slower in FF than in Chrome, stock, etc.

As for (2), I've seen this on 3 different devices, plus comment 16 reports the same issue. I can nonetheless provide touch event data later -- this unfortunately requires installing the android developer tools, but I can do that.

However, since cwiis said in comment 22 that he thought this was a UX bug, I think it's reasonable to leave it open as that, unless someone made the decision to make FF scrolling slower intentionally when switching from XUL Fennec to Java Fennec.

Comment 27

[Kartikaya Gupta (email:[e-mail])]

I discussed with Ian (our UX designer) and he said that the scrolling speed is fine the way it is now (so this is not a UX bug), but that we need some sort of accelerated scrolling. That is a separate issue being tracked in bug 721421.

So I guess the only thing left is for you to get that data you promised.

Comment 28

[bug.zilla]

I think the issue is not just the acceleration when a user scrolls faster.

For me the main issue is that scrolling does not decay smoothly. This is really noticeable even on a Galaxy S4.

It seems that as scrolling slows down it becomes much jerkier like it's doing some heavy I/O.

Comment 29

[Chris Lord [:cwiiis]]

We have accelerated scrolling in both fennec and b2g, I don't think this bug is valid anymore.