There is a good chance this is due to my CL in the bisect above. I am trying to repro and investigate more.

This issue is reproducible on Linux as well by passing switches --touch-events=enabled and --touch-devices=ID where ID could be the mouse id obtained from 'xinput list' bash command.

I also have found a fix for the issue. This is the CL for it. But since there is a conflicting CL in CQ soon, I will wait for that one to land and rebase onto it and send out for reviews.

Here is the blocking CL: https://codereview.chromium.org/2240553003/
Here is the fix: https://codereview.chromium.org/2255363002/

Just to update, this is a Regression in M54, so adding RB Label. Please feel free to remove if not required.
Thank You.

My fix is working but there are some Chrome OS test failures I will try to resolve today. I will send this out for review then and hopefully land it before the cut to avoid merges.

Also, based on #2 this is also happening on Linux. I have not verified on ChromeOS but I believe it should happen there as well since this is an Aura thing.

Friendly ping to get an update on this issue.

The patch in comment #2 fixes the issue. It is under review and close to landing soon.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9135773062a5f13e51348454c682d6661447c887

commit 9135773062a5f13e51348454c682d6661447c887
Author: ekaramad <ekaramad@chromium.org>
Date: Tue Aug 23 18:45:29 2016

TextInputManager::GetTextSelection() should be called on focused widget.

Currently, in the following methods in RenderWidgetHostViewAura, we use
the active widget, i.e., the widget with focused text field to get text
selection information:
GetTextRange()
GetSelectionRange()
GetTextFromRange()

Using the active widget as opposed to the focused widget regressed the
long press touch quick menu on Aura. This is due to the call to
GetSelectionRange() which returns empty when the selection is on a
non-editable text. Using the focused widget is correct and fixes the
issue.

The corresponding unit tests are also modified so that we now test the
selection on "focused widget" as opposed to "active widget".

BUG= 638898 ,  602723 ,  578168 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2255363002
Cr-Commit-Position: refs/heads/master@{#413795}

[modify] https://crrev.com/9135773062a5f13e51348454c682d6661447c887/content/browser/frame_host/render_widget_host_view_child_frame.cc
[modify] https://crrev.com/9135773062a5f13e51348454c682d6661447c887/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/9135773062a5f13e51348454c682d6661447c887/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc

I tested this on Linux and after the patch it is fixed. Can someone verify if the issue has been fixed on a Windows 10 device? The fix is in Canary now. Thanks.

 Issue 622677  has been merged into this issue.

I tested this on a Windows 10 touch device on Chrome Canary today. Long pressing shows the quick menu now so the fix is working as intended. Marking this bug as fixed.