context menu steals focus from the webview

Bug #1526884 reported by Bill Filler on 2015-12-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Bill Filler
webbrowser-app (Ubuntu)
High
Olivier Tilloy

Bug Description

latest rc-proposed on krillin

1) open webbrowser-app and find a link
2) long press to get context menu and select "Copy Link"
3) open gmail webapp and create a new message
4) go to the message body and try to paste the link by long pressing, and selecting "Paste" from the menu

Expected results:
link pasted into message body

Actual results:
nothing pasted into the message body

Some additional info:
- instead of doing step 4) try to paste into the "To" field and it works correctly, so the paste buffer has the correct info, just can't be pasted into the body of the message

- also, if I type some text in the message body, the long press->"Select all", then long press->"copy", and then long press "paste" nothing happens.

Related branches

Olivier Tilloy (osomon) wrote :

I fail to reproduce the issue. Tested on both krillin and arale running latest rc-proposed, also tested with oxide 1.11.3 from silo 57, pasting a link into gmail new message field always works for me.

Changed in webbrowser-app (Ubuntu):
status: New → Incomplete
Bill Filler (bfiller) wrote :

seeing same behavior in twitter, where i can't paste into the New Tweet field

once in a while I can get the paste to work if I try 3 or 4 times, but not sure how to trigger it. Seems like it's related to focus of the field and perhaps the focus of the field is getting lost when the context menu is being displayed so it doesn't know where to paste the results. It does seem like the context menu is causing the osk to hide/show after selecting the paste option so guessing this is the cause

Olivier Tilloy (osomon) on 2015-12-16
summary: - cannot paste from webbrowser-app into gmail webapp
+ context menu steals focus from the webview
Changed in webbrowser-app (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → High
Olivier Tilloy (osomon) wrote :

This (the fact that the context menu steals focus from the webview) can easily be observed in the browser by tapping on a text field to focus it (the OSK comes up), then long-pressing on that field to open the context menu: the OSK disappears, and doesn’t come back up when dismissed.

Olivier Tilloy (osomon) wrote :

The context menu should never steals focus from the webview (stealing it and restoring it afterwards doesn’t sound good enough, as it would make the OSK hide/show again unnecessarily).

Changed in webbrowser-app (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
Olivier Tilloy (osomon) wrote :

Unfortunately for the browser case (where the context menu is implemented as a modal Dialog), we’re out of luck because the implementation of Dialog explicitly grabs focus when becoming visible (see https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/src/Ubuntu/Components/Popups/1.3/Dialog.qml#L147).

Olivier Tilloy (osomon) wrote :

For the default context menu exposed by the Ubuntu WebView (which is what is used in e.g. the gmail webapp), the implementation uses an ActionSelectionPopover, which inherits Popover, which doesn’t steal focus when displayed. However tapping an action in the menu does steal the focus.

If I change the implementation of Popover (/usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu/Components/Popups/1.3/Popover.qml) to not request active focus on press (https://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/src/Ubuntu/Components/Popups/1.3/Popover.qml#L209), then the webview retains focus as expected.

Olivier Tilloy (osomon) wrote :

Applying the above workaround without modifying the UITK is easy enough with the following trick, inside the context menu component:

    Binding {
        target: __foreground
        property: "activeFocusOnPress"
        value: false
    }

This works for context menu implementations based on Popover (or ActionSelectionPopover), but unfortunately it doesn’t for the browser’s mobile implementation, which inherits Dialog, because Dialog also does this:

    Component.onCompleted: foreground.forceActiveFocus()

Not sure how to inhibit this behaviour.

Olivier Tilloy (osomon) wrote :

> Not sure how to inhibit this behaviour.

Until we come up with a better solution, we can at the very least restore active focus on the webview when closing the context menu.

Changed in webbrowser-app (Ubuntu):
status: Confirmed → In Progress
Bill Filler (bfiller) on 2015-12-16
Changed in canonical-devices-system-image:
milestone: none → ww02-2016
assignee: nobody → Bill Filler (bfiller)
importance: Undecided → High
status: New → In Progress
Olivier Tilloy (osomon) wrote :

The problem has gotten worse with the latest release of the UITK (1.3.1778+16.04.20151217.1-0ubuntu1). With the fix for bug #1523828, popovers are now requesting active focus when they are shown, so the workaround I mentioned in comment #7 is useless.

In gmail, when long pressing on the compose field of a new message, the webview looses focus, which hides the OSK, which resizes the webview, which as a consequence dismisses the context menu. So the context menu has become unusable in gmail.

Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package webbrowser-app - 0.23+16.04.20160112.1-0ubuntu1

---------------
webbrowser-app (0.23+16.04.20160112.1-0ubuntu1) xenial; urgency=medium

  [ CI Train Bot ]
  * Resync trunk. added: po/et.po

  [ Michael Sheldon ]
  * Dynamically load the thumbnailer image provider if it's available,
    otherwise fallback to mimetype images (LP: #1531179)

  [ Olivier Tilloy ]
  * Address a number of minor functional and code issues in the new
    downloads-in-browser functionality. (LP: #1528651)
  * Restore active focus on the webview after closing the context menu.
    (LP: #1526884)

 -- Olivier Tilloy <email address hidden> Tue, 12 Jan 2016 17:44:22 +0000

Changed in webbrowser-app (Ubuntu):
status: In Progress → Fix Released
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers