Touch selection menu initially empty when focusing a text field

Bug #1586968 reported by Olivier Tilloy on 2016-05-30
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Oxide
High
Olivier Tilloy
1.15
High
Olivier Tilloy
webbrowser-app (Ubuntu)
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).

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

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.

Olivier Tilloy (osomon) wrote :

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)
Olivier Tilloy (osomon) wrote :

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.

Changed in oxide:
status: Confirmed → In Progress
Changed in webbrowser-app (Ubuntu):
status: Triaged → Invalid
Olivier Tilloy (osomon) on 2016-06-01
Changed in oxide:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers