Ubuntu
webbrowser-app package

Touch selection menu initially empty when focusing a text field

Bug #1586968 reported by Olivier Tilloy on 2016-05-30

This bug affects 2 people

	Status	Importance	Assigned to	Milestone
Oxide	Fix Released	High	Olivier Tilloy
1.15	Fix Released	High	Olivier Tilloy	Oxide 1.15.7
webbrowser-app (Ubuntu)	Invalid	High	Olivier Tilloy

Bug Description

This appears to be 100% reproducible when the device has just been rebooted (not always reproducible otherwise).
Steps to reproduce:
1) browse to e.g. http://pastebin.ubuntu.com
2) long press on one of the text fields ("Poster:" or "Content:")
3) wait for the touch selection menu to appear next to the insertion handle (note that at the moment there is a bug in oxide which also triggers the page context menu, dismissing it will get you the touch selection menu)

Expected result: assuming the clipboard is empty (device just rebooted), the "Select All" action is the only one visible in the touch selection menu.

Current result: no action is visible, the menu is empty (see attached screenshot).

Related branches

lp:oxide/1.15

lp:~oxide-developers/oxide/packaging.xenial

lp:~oxide-developers/oxide/packaging.wily

lp:~oxide-developers/oxide/packaging.trusty

lp:~oxide-developers/oxide/packaging.xenial.overlay

lp:~oxide-developers/oxide/packaging.vivid.overlay

lp:~oxide-developers/oxide/packaging.yakkety

Revision history for this message

Olivier Tilloy (osomon) wrote on 2016-05-30:

empty-touch-selection-menu.png Edit (84.2 KiB, image/png)

Changed in webbrowser-app (Ubuntu):
status:	New → Triaged
assignee:	nobody → Olivier Tilloy (osomon)
importance:	Undecided → High

Revision history for this message

Olivier Tilloy (osomon) wrote on 2016-05-30:

I instrumented the webview to print the initial value of editingCapabilities (at Component.onCompleted) and to print the new value whenever it changes. This is what I’m seeing:

qml: EDITING CAPS: 0
qml: INITIAL EDITING CAPS: 64

The value of editingCapabilities changes once (to 0) before component completion. At component completion, the value has changed again (64 == SelectAll), but the corresponding changed signal hasn’t been emitted, which explains why the touch selection menu isn’t aware of the SelectAll capability, and is displayed empty. This looks like a bug in oxide.

Revision history for this message

Olivier Tilloy (osomon) wrote on 2016-05-30:

Emitting 'editingCapabilitiesChanged' in OxideQQuickWebViewPrivate::completeConstruction() does the trick, but I’m not entirely sure this is the best approach.

Changed in oxide:
status:	New → Confirmed
importance:	Undecided → High
assignee:	nobody → Olivier Tilloy (osomon)

Revision history for this message

Olivier Tilloy (osomon) wrote on 2016-05-30:

I see what’s happening: when OxideQQuickWebViewPrivate::OnEditingCapabilitiesChanged() is initially called, the value of the edit flags stored by the oxide webview is correct (64 == SelectAll), but to retrieve the new value OxideQQuickWebView::editingCapabilities() is called, and at that point (component construction not complete yet), d->proxy_ is null, so NoCapability (0) is returned.

In this light, emitting editingCapabilitiesChanged() in OxideQQuickWebViewPrivate::completeConstruction() after the proxy has been set sounds like a reasonable solution.