Scrolling performance is dreadful after text has been selected

Bug #1569315 reported by Chris Coulson on 2016-04-12
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
High
Chris Coulson
1.15
High
Chris Coulson

Bug Description

I just noticed this - after selecting text with the mouse (I haven't tried this on the phone yet), scrolling becomes very laggy. It normally doesn't recover after cancelling the selection.

chrome://tracing shows the UI thread is blocking for ~50ms periods in MessageLoop::RunTask, which isn't particularly helpful. The task being executed was posted from IPC::ChannelProxy::Context::OnMessageReceivedNoFilter, so it's basically a message handler somewhere that's responsible.

Bug 1565280 would really help here.

Chris Coulson (chrisccoulson) wrote :

This happens on every branch for me

Olivier Tilloy (osomon) on 2016-04-12
Changed in oxide:
status: New → Confirmed
Changed in oxide:
importance: Undecided → High
status: Confirmed → Triaged
Olivier Tilloy (osomon) on 2016-04-12
Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Olivier Tilloy (osomon)
Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
milestone: none → branch-1.16
Changed in oxide:
status: Triaged → In Progress
Chris Coulson (chrisccoulson) wrote :

There's multiple issues here:

1) Oxide is reading data from the clipboard every time the selection bounds change, in order to update the editing capability flags. This is really expensive (more than 50ms!)

2) Selections aren't always completely cancelled in Blink, and we continue to receive selection bounds updates with focus_rect == anchor_rect as content is scrolled.

3) Scrolling over active Flash content causes us to begin to receive selection bounds updates (again, with focus_rect == anchor_rect) as content is scrolled.

Chris Coulson (chrisccoulson) wrote :
Changed in oxide:
status: In Progress → Fix Released
no longer affects: webbrowser-app (Ubuntu)
Chris Coulson (chrisccoulson) wrote :

The changes required to fix this are quite intrusive (it depends on https://git.launchpad.net/oxide/commit/?id=f99ce23c7d1880b8b083c4d13e496ca976606d15 as well). I'd like to fix this in 1.15, but for that branch I wonder whether to just stop checking the clipboard contents in WebView::EditingCapabilitiesChanged and effectively advertise that Paste is enabled when any editable node is focused. This would obviously be a small regression in the API for the 1.15 release, but it's probably worth it to have this fixed.

What are your thoughts Olivier?

Olivier Tilloy (osomon) wrote :

I think this is a reasonable trade-off to have the issue fixed in 1.15.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers