Oxide

Scrolling performance is dreadful after text has been selected

Bug #1569315 reported by Chris Coulson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
High
Chris Coulson
Oxide branch-1.16
1.15
Fix Released
High
Chris Coulson
Oxide 1.15.5

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.

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

This happens on every branch for me

Olivier Tilloy (osomon)
Changed in oxide:
status: New → Confirmed
Chris Coulson (chrisccoulson)
Changed in oxide:
importance: Undecided → High
status: Confirmed → Triaged
Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Olivier Tilloy (osomon)
Chris Coulson (chrisccoulson)
Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
milestone: none → branch-1.16
Chris Coulson (chrisccoulson)
Changed in oxide:
status: Triaged → In Progress
Revision history for this message
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.

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

Fixed with https://git.launchpad.net/oxide/commit/?id=0cf0e457da8772747e764c200428ae3fdbb659e1

Changed in oxide:
status: In Progress → Fix Released
no longer affects: webbrowser-app (Ubuntu)
Revision history for this message
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?

Revision history for this message
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  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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