Select All shows up when replying to gmail message

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

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

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

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.

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.

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.

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.

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.

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.

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

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).

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.