More natural scrolling

Bug #1389777 reported by Jean-Baptiste Lallement
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
Low
Chris Coulson
oxide-qt (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Scroll feels very unnatural. I can swipe up to start scrolling but almost immediately it slows down and then stops. This means I had to swipe 5-10 times to go to the bottom of the page.
I would prefer for page to keep scrolling until I stop it (so swipe up quickly and then just wait for scroll to finish)

ProblemType: Bug
DistroRelease: Ubuntu RTM 14.09
Package: webbrowser-app 0.23+14.10.20141028~rtm-0ubuntu1
Uname: Linux 3.4.67 armv7l
ApportVersion: 2.14.7-0ubuntu8
Architecture: armhf
Date: Wed Nov 5 17:29:57 2014
InstallationDate: Installed on 2014-11-05 (0 days ago)
InstallationMedia: Ubuntu Utopic Unicorn (development branch) - armhf (20141105-120036)
SourcePackage: webbrowser-app
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
Olivier Tilloy (osomon)
affects: webbrowser-app (Ubuntu) → oxide-qt (Ubuntu)
Changed in oxide:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in oxide-qt (Ubuntu):
status: New → Confirmed
Revision history for this message
Jim Hodapp (jhodapp) wrote :

Scrolling is also very jumpy. If you down scroll very slowly, the page jumps in the opposite direction randomly. The slowness of the address bar also makes scrolling very annoying to use.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

I'm keeping this bug focused specifically on the speed at which flings decelerate, which I've improved significantly on trunk (with a bit of trial and error, so it could still probably be improved).

As for the other issues:

- The addressbar issues are covered by bug 1370366 (the renderer compositor will calculate the header position, as it does on Chrome Android)
- I'm aware of the jumpy scrolling. I'm not sure what's causing it yet, but it does seem to be Krillin specific

Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
milestone: none → branch-1.4
status: Triaged → Fix Released
Revision history for this message
David Barth (dbarth) wrote : Re: [Bug 1389777] Re: More natural scrolling

Chris: on the jumpiness, i'm also observing that on the N4, though to a
lesser extent. I suspect this is due to actual touch events going in the
wrong direction, and which should be filtered out by some extra logic.

On Mon, Nov 17, 2014 at 11:50 PM, Chris Coulson <<email address hidden>
> wrote:

> I'm keeping this bug focused specifically on the speed at which flings
> decelerate, which I've improved significantly on trunk (with a bit of
> trial and error, so it could still probably be improved).
>
> As for the other issues:
>
> - The addressbar issues are covered by bug 1370366 (the renderer
> compositor will calculate the header position, as it does on Chrome Android)
> - I'm aware of the jumpy scrolling. I'm not sure what's causing it yet,
> but it does seem to be Krillin specific
>
> ** Changed in: oxide
> Assignee: (unassigned) => Chris Coulson (chrisccoulson)
>
> ** Changed in: oxide
> Milestone: None => branch-1.4
>
> ** Changed in: oxide
> Status: Triaged => Fix Released
>
> --
> You received this bug notification because you are a member of Oxide
> Developers, which is subscribed to oxide-qt in Ubuntu.
> Matching subscriptions: oxide in Ubuntu
> https://bugs.launchpad.net/bugs/1389777
>
> Title:
> More natural scrolling
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/oxide/+bug/1389777/+subscriptions
>

Revision history for this message
Jim Hodapp (jhodapp) wrote :

@Chris: the jumpiness is mostly on the N7 for me. It's very easy to reproduce, just simply touch your finger to the browser window to scroll and very slowly scroll up like you want to read further down the page. Sometimes it jumps 2-3 pages worth. It'll do this to me as well scrolling even a bit faster, but it seems the faster you scroll the more reliable it is and the less it jumps.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I see this too on Nexus 4.

Changed in oxide-qt (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package oxide-qt - 1.4.2-0ubuntu0.14.10.1

---------------
oxide-qt (1.4.2-0ubuntu0.14.10.1) utopic-security; urgency=medium

  * Update to v1.4.2 (see USN-2476-1)
    - Bump Chromium rev to 40.0.2214.91
    - Fix LP: #1297973 - Don't allow the BrowserContext to be deleted until
      the render thread is quit in single process mode
    - Fix LP: #1321969 - Add proper API for handling page closing:
      + Add WebView.prepareToClose() which runs the current page's
        beforeunload handler
      + Add WebView.prepareToCloseResponse signal, which tells the embedder
        whether a close should proceed
      + Add WebView.closeRequested signal, driven from window.close()
      + Ensure the current page's unload handler runs when a WebView is deleted
    - Fix LP: #1353143 - Add an API for saving and restoring the state of a
      WebView, used for session restore in the browser
    - Fix LP: #1374494 - Warnings when processing GPU blacklist
    - Fix LP: #1283291 - Cannot use multiple BrowserContexts in single-process
      mode. Make WebView.context read-only in single-process mode (all
      WebViews will use a default WebContext)
    - Fix LP: #1326115 - Disable WebView.incognito in single-process mode. It
      relies on using multiple BrowserContexts, which is not possible in
      single process
    - Fix LP: #1249147 - Use TCMalloc in the renderer process
    - Fix LP: #1389777 - More natural scrolling - tweak the gesture fling curve
    - Fix LP: #1398941 - Tidy up the LoadEvent sequence for failed loads
    - Fix LP: #1381558 - Fix crash in
      oxide::CompositorThreadProxy::SendSwapSoftwareFrameOnOwnerThread
    - Fix LP: #1402382 - Fix a potential memory leak because of a refcount race
    - Fix LP: #1398087 - Fix application crash when accessing
      navigator.webkitPersistentStorage.requestQuota
    - Really fix LP: #1391230 - Release the screen dim lock when the
      application becomes inactive
    - Turn pinch virtual viewport on for mobile form factors
    - Limit the maximum decoded image size on mobile
    - Remove the screen-dim lock when the application goes in to the background
      (and restore it when it comes back in to the foreground)
    - Don't create OTR BrowserContexts unnecessarily
    - Add an experimental API for changing the process model
      (Oxide.processModel)
    - Don't leak WebPreferences if the WebView is deleted without ever
      accessing WebView.preferences
    - Add support for component builds
  * Refresh gross-hack-for-dual-ffmpeg-build.patch
 -- Chris Coulson <email address hidden> Thu, 20 Nov 2014 11:01:29 +0000

Changed in oxide-qt (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package oxide-qt - 1.4.2-0ubuntu0.14.04.1

---------------
oxide-qt (1.4.2-0ubuntu0.14.04.1) trusty-security; urgency=medium

  * Update to v1.4.2 (see USN-2476-1)
    - Bump Chromium rev to 40.0.2214.91
    - Fix LP: #1297973 - Don't allow the BrowserContext to be deleted until
      the render thread is quit in single process mode
    - Fix LP: #1321969 - Add proper API for handling page closing:
      + Add WebView.prepareToClose() which runs the current page's
        beforeunload handler
      + Add WebView.prepareToCloseResponse signal, which tells the embedder
        whether a close should proceed
      + Add WebView.closeRequested signal, driven from window.close()
      + Ensure the current page's unload handler runs when a WebView is deleted
    - Fix LP: #1353143 - Add an API for saving and restoring the state of a
      WebView, used for session restore in the browser
    - Fix LP: #1374494 - Warnings when processing GPU blacklist
    - Fix LP: #1283291 - Cannot use multiple BrowserContexts in single-process
      mode. Make WebView.context read-only in single-process mode (all
      WebViews will use a default WebContext)
    - Fix LP: #1326115 - Disable WebView.incognito in single-process mode. It
      relies on using multiple BrowserContexts, which is not possible in
      single process
    - Fix LP: #1249147 - Use TCMalloc in the renderer process
    - Fix LP: #1389777 - More natural scrolling - tweak the gesture fling curve
    - Fix LP: #1398941 - Tidy up the LoadEvent sequence for failed loads
    - Fix LP: #1381558 - Fix crash in
      oxide::CompositorThreadProxy::SendSwapSoftwareFrameOnOwnerThread
    - Fix LP: #1402382 - Fix a potential memory leak because of a refcount race
    - Fix LP: #1398087 - Fix application crash when accessing
      navigator.webkitPersistentStorage.requestQuota
    - Really fix LP: #1391230 - Release the screen dim lock when the
      application becomes inactive
    - Turn pinch virtual viewport on for mobile form factors
    - Limit the maximum decoded image size on mobile
    - Remove the screen-dim lock when the application goes in to the background
      (and restore it when it comes back in to the foreground)
    - Don't create OTR BrowserContexts unnecessarily
    - Add an experimental API for changing the process model
      (Oxide.processModel)
    - Don't leak WebPreferences if the WebView is deleted without ever
      accessing WebView.preferences
    - Add support for component builds
  * Refresh gross-hack-for-dual-ffmpeg-build.patch
 -- Chris Coulson <email address hidden> Thu, 15 Jan 2015 15:38:02 +0000

Changed in oxide-qt (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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