Ubuntu
webbrowser-app package

[browser] scrolling uneven and queues up

Bug #1584965 reported by Bill Filler
142
This bug affects 40 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
High
Bill Filler
Canonical System Image backlog
Oxide
Confirmed
High
Santosh
webbrowser-app (Ubuntu)
Confirmed
High
Unassigned

Bug Description

I've noticed this on a bunch of websites, mainly on Arale but also on krillin, both running latest rc-proposed with and without oxide 1.15

The scenario is I'm on page A, navigate to page B, press back button, then try to scroll page A (flicking up). The page doesn't move for a short time then scrolls super fast almost to the bottom. Seems like the scroll events are getting queued up and then all applied at once.

This site reproduces it pretty easy for me:

1) goto boston.craigslist.org
2) type "kayak" in the search field
3) you'll get a page full of results
4) click on one of the results
5) wait till page fully loads, flick quickly a few times, first flicks ignored. then press back button
6) wait till page fully loads and then start scrolling (flicking up, multiple times), first flicks ignored/queued then scrolling happens fast

Expected results:
the page should start scrolling immediately and keep up with action of finger

Actual results:
the page is not responsive for a few seconds then scrolls super fast toward the bottom

Revision history for this message
Bill Filler (bfiller) wrote :

Here is a video that shows it:
https://www.dropbox.com/s/4lpom34glkud238/File%20May%2023%2C%205%2009%2020%20PM.mov?dl=0

Changed in webbrowser-app (Ubuntu):
importance: Undecided → High
assignee: nobody → Olivier Tilloy (osomon)
summary: - scrolling uneven and queues up
+ [browser] scrolling uneven and queues up
Changed in canonical-devices-system-image:
importance: Undecided → High
assignee: nobody → Bill Filler (bfiller)
milestone: none → backlog
Revision history for this message
Olivier Tilloy (osomon) wrote :

I can easily observe the same kind of issue with slashdot.org on my krillin running rc-proposed:
 - browse to slashdot.org, wait for the main page to be loaded
 - tap on an article headline to open it
 - wait for the page to be fully loaded, tap the back button
 - flick the page once

It seems that if I wait long enough after the main page has been loaded back (a few seconds), then the issue cannot be reproduced, so I’m guessing this is linked to loading/rendering not being fully complete by the time the flick gesture is delivered.

Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
Pat McGowan (pat-mcgowan)
Changed in canonical-devices-system-image:
status: New → Confirmed
Revision history for this message
Robin Heroldich (robinheroldich) wrote :

This is one of the most annoying issues with the browsing experience. Could you figure out a solution for OTA-14? I'd really appreciate it. Thanks. :)

Olivier Tilloy (osomon)
Changed in oxide:
importance: Undecided → High
assignee: nobody → Santosh (santoshbit2007)
status: New → Confirmed
Revision history for this message
Santosh (santoshbit2007) wrote :

Initial investigation: There seems to be a blocking of task by blink scheduler because of prioritization of other task. So this may be result of side effect of blink scheduler policy.
Need to check more before any conclusion.
I get this log on console thrown by blink scheduler while scrolling on slashdot.org

qml: [JS] (https://slashdot.org/:0) Blink deferred a task in order to make scrolling smoother. Your timer and network tasks should take less than 50ms to run to avoid this. Please see https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail and https://crbug.com/574343#c40 for more information.

Revision history for this message
Santosh (santoshbit2007) wrote :

I tried to reproduce the same bug on Arale but to me it looks somewhat ok. I am using lastest oxide. There has been some changes in upstream chromium which might resolved this issue(https://crbug.com/574343#c40).

I can see similar janked scrolling when I use --disable-features=SchedulerExpensiveTaskBlocking
Which was default in chromium sometime before.

I feel bug should not occur in latest oxide. Could you confirm that this bug is happening with latest trunk oxide also

Revision history for this message
Santosh (santoshbit2007) wrote :

Bill confirmed that scrolling is quite improved with latest oxide1.17 and the same issue
is not observable.

Revision history for this message
Santosh (santoshbit2007) wrote :

Some part of bug may be related https://bugs.launchpad.net/oxide/+bug/1643428 (May be)

Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
assignee: Olivier Tilloy (osomon) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.