Closed Bug 716776 Opened 10 years ago Closed 6 years ago

Scrolling is much slower than stock, xul fennec on Android

Categories

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

30 Branch
ARM
Android
defect

Tracking

(fennec+)

RESOLVED WORKSFORME
Tracking Status
fennec + ---

People

(Reporter: samth, Assigned: samth)

References

()

Details

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]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just for reference, this is on an HTC Sensation with Android 2.3.1.
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).
(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?
The friction setting has got some complaints via SUMO and MTD. Maybe we need to ease it up a bit?
Assignee: nobody → pwalton
tracking-fennec: --- → 11+
Priority: -- → P3
(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.
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.
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.
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Err, sorry. WONTFIX is a better resolution for now.
Resolution: INVALID → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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
Summary: Scrolling is much slower than stock, xul fennec → Scrolling is much slower than stock, xul fennec on HTC Sensation
Ok, I'll do that.  I may not be able to get to it for a little while, but I will.
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.
Assignee: pwalton → chrislord.net
tracking-fennec: 11+ → +
Assignee: chrislord.net → nobody
Component: General → Graphics, Panning and Zooming
Oops, accidentally reset assignee.
Assignee: nobody → chrislord.net
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?
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?
Frederik: the "jumpy scrolling" may be bug 805479.
Could be true, thanks. 
But also the scrolling speed seems to be slower than the stock browser. 
Any about:config settings to tweak?
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.
I'm unassigning this - as far as I can tell, our scroll speeds are deliberate and this is a UX issue (or bug 708765).
Assignee: chrislord.net → nobody
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?
(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.
Whiteboard: [mentor=kats]
Summary: Scrolling is much slower than stock, xul fennec on HTC Sensation → Scrolling is much slower than stock, xul fennec on Android
Version: Firefox 11 → Firefox 30
This is not actionable as I never got the data I asked for in comment 11 and we can't reproduce unexpectedly slow scrolling.
Status: REOPENED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [mentor=kats]
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.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
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.
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Resolution: --- → INCOMPLETE
(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.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
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.
Assignee: nobody → samth
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.
We have accelerated scrolling in both fennec and b2g, I don't think this bug is valid anymore.
Status: REOPENED → RESOLVED
Closed: 8 years ago6 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.