Select All shows up when replying to gmail message

Bug #1570511 reported by Bill Filler
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Fix Released
High
Bill Filler
Oxide
Fix Released
High
Olivier Tilloy
1.15
Fix Released
High
Olivier Tilloy
webbrowser-app (Ubuntu)
Fix Released
High
Olivier Tilloy

Bug Description

open gmail webapp (or in browser), try to reply to a mail
scroll to the top of the message and tap to begin typing

expected result:
- can start typing, no menu

actual result:
- can start typing but Select All menu is incorrectly displayed

Related branches

Bill Filler (bfiller)
Changed in canonical-devices-system-image:
milestone: none → 11
assignee: nobody → Bill Filler (bfiller)
importance: Undecided → High
Changed in webbrowser-app (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
Revision history for this message
Olivier Tilloy (osomon) wrote :

The same issue can be observed when replying to a tweet in twitter (from duplicate bug #1567140).

Changed in canonical-devices-system-image:
status: New → Confirmed
Bill Filler (bfiller)
tags: added: system-apps-11
Revision history for this message
Olivier Tilloy (osomon) wrote :

Just tested with oxide trunk, the issue is still there.

Revision history for this message
Olivier Tilloy (osomon) wrote :

The insertion handle (and the quick menu with the "Select All" option together with it) is initially shown if the text input/area isn’t empty, which is typically the case when replying to an e-mail (where the original message is quoted) or to a tweet (the nickname of the original author is added).

Writing a new tweet or a new blank e-mail doesn’t exhibit this behaviour.

So I need to figure out whether automatically showing the insertion handle when the text input isn’t empty can be disabled in oxide.

affects: webbrowser-app (Ubuntu) → oxide
Revision history for this message
Olivier Tilloy (osomon) wrote :

In TouchSelectionController::WillHandleTapEvent(…), the insertion handle is automatically shown if the text input is not empty, and then deactivated if (selection_empty_ && !config_.show_on_tap_for_empty_editable):

  […]
  ShowInsertionHandleAutomatically();
  if (selection_empty_ && !config_.show_on_tap_for_empty_editable)
    DeactivateInsertion();
  […]

Given that the selection is empty (and that config.show_on_tap_for_empty_editable is always false), the insertion handle should in theory be deactivated, but in practice I’m seeing that selection_empty_ is false. It looks like that flag is not being updated correctly.

Revision history for this message
Olivier Tilloy (osomon) wrote :

The selection_empty_ flag is set by TouchSelectionController::OnSelectionEmpty(bool), which is being called at the end of RenderWidgetHostView::OnSwapCompositorFrame(). Oxide’s implementation is very similar to RenderWidgetHostViewAura, I wonder where the issue lies.

Revision history for this message
Olivier Tilloy (osomon) wrote :

It turns out TouchSelectionController::OnSelectionEmpty(true) is being called shortly (milliseconds) after TouchSelectionController::WillHandleTapEvent() where the value of selection_empty_ is being checked.

Setting selection_empty_ to true doesn’t trigger an update of the insertion handle, I wonder whether that should be considered a bug in chromium. Couldn’t find any open issue in the chromium bug tracker for that.

Revision history for this message
Olivier Tilloy (osomon) wrote :

Another symptom of that issue (initially reported as bug #1577696):
 - ensure that you have some text in the clipboard
 - browse to a page that has an empty textarea (e.g. any launchpad bug page when logged in)
 - ensure that the text area is not focused
 - long press on the text area

Expected result: one contextual menu with Paste option.

Current result: the insertion handle together with the quick menu is shown, as well as the contextual menu.

Changed in canonical-devices-system-image:
milestone: 11 → 12
Revision history for this message
Bill Filler (bfiller) wrote :

This is an issue on multiple sites (just hit it again on connect.garmin.com, see bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyboard/+bug/1584847)

Seems like Select All being incorrectly shown whenever focusing any non-empty text field or text area.

Revision history for this message
Bill Filler (bfiller) wrote :

actually and also on some text fields that are empty too..

Revision history for this message
Olivier Tilloy (osomon) wrote :

I’m playing around with chrome on android to see how it behaves, and I see that the insertion handle is always being shown when focusing a non-empty text field, which is also what oxide does.

The difference is that in chrome on android the quick menu isn’t shown along with the insertion handle until the handle is tapped. We could implement something similar in the browser: do not show the quick menu for the insertion handle until it is tapped.

I haven’t seen the issue described by Bill in comment #10 though (insertion handle being shown in empty text fields).

Revision history for this message
Olivier Tilloy (osomon) wrote :

To fix this issue I ended up adding a 'quickMenuRequested' property to the touch selection controller API, which closely mimics what is done in the aura implementation in chromium.

Changed in oxide:
status: Confirmed → In Progress
Changed in webbrowser-app (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → High
status: New → Confirmed
Olivier Tilloy (osomon)
Changed in oxide:
status: In Progress → Fix Released
Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
status: Confirmed → In Progress
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Olivier Tilloy (osomon)
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
Olivier Tilloy (osomon)
Changed in webbrowser-app (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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