Note, I would only expect to see Paste when there's actually data in the clipboard.  If no data in clipboard, Paste should be suppressed.

Yes, that's the plan.

Any update? Will this make into m53 release?

I'm refactoring the context menu code and will fix this simultaneously. Do you need this for M53?

I personally would vote for sooner vs later, but I am not on the Chrome RelTeam :-)

Any update? Will this make into m54 release?

amaralp@ is working full-time on the text selection refactoring which includes this bug.  It's coming along.  It's fairly likely to make 54 branch point, and if it misses I'll evaluate cherry-picking it to 54.

Marking this 54 blocker to make sure it doesn't fall off the radar.

Punting to 55 because the launch train for http://b/27746617 is delayed due to missing spellcheck support.

This bug has been moved to M-56. The relevant bug for http://b/27746617 is now crrev.com/652916.

Why does this keep getting punted?  :-(

Because our code for floating action popup is pretty old and busted and we're more or less rewriting the whole thing to fix this bug and others.

Maybe a stupid question, but why not use the platform/support library API's around this?  Any rough idea when this will land?

We have to reinvent a lot of wheels in text editing and scrolling, since the support libraries don't speak HTML.

The latest rough idea is M56, see https://www.chromium.org/developers/calendar for correlated dates.

Thanks for the details.

Separately, should we try to fix that to make reinventing less of a need?  If so, perhaps file an internal bug against view's or support library and we can figure out how to best route it?  Feel free to CC me.

I have no complaints about the APIs Android provides in this area -- it has all the hooks we need.

In general, we can't use platform support libraries much at all for anything inside the web content area (this is the case not only on Android but also Windows, Mac and Linux).  We present it to the system as a bunch of pixels rendered with OpenGL/Vulkan within a single View.  We have very detailed and specific commitments for W3C standards that we can't even start to match using the higher-level constructs that the support libraries understand.

Ah, OK, just figured if there was something we could do better on the Android side, it'd be great to work together to make things better.

Well, either way, I am looking forward to this bug being fixed, so if you need help testing, please do let me know!

Friendly ping on this?  This bug is also present in Gmail, where long pressing doesn't show Select All in the floating toolbar.

I'd rather fix this along with a more general context menu refactor. If you'd like this fixed now I could probably make a work around.

I think it would be good to workaround if possible for now if the refactor is several releases out.  Right now WebView feels "broken" compared to native EditText's on text selection/editing.

When is the general refactor taking place?

I'm aiming to have the refactor in for M58.

How far out is that, and what would be the earliest that we could do a workaround?  ie, is the effort for the workaround worth it, or not really?  It'd be nice to make this better before a large refactoring.

M58 would go out to Stable on April 27th. The workaround would go in with M57 which would go out to Stable on March 14th.

The problem with the workaround is that it needs to know whether the selected text box is empty. This makes it have to rely on information from a separate thread which could cause flakiness.

ACK, up to you I guess, I trust your judgement!

Hey all, wanted to check if this is on track for M58.  I am on M58 now, and still see this issue.

Currently working on this. The Blink side code is being reviewed at: https://codereview.chromium.org/2712603007. The entire fix should make it into M58.

Thanks! Is this still looking on track? I still see this broken and I'm on M58

It didn't make it into M58. The contenteditable case turned out to be trickier than expected. I have a CL (https://codereview.chromium.org/2787893004) to handle that case.

Is there any chance this might be able to slip in to M58?

It would be difficult to get it into M58. The branch point is in one week and several CLs would have to be cherry picked. I think the risk of introducing a bug into Stable outweighs the benefits.

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

commit 8bf0dbc4326668e5a12f974f783e5543b78fe4f9
Author: amaralp <amaralp@chromium.org>
Date: Wed Apr 12 19:26:29 2017

Add Select All to Android floating insertion menu

Currently the insertion paste popup menu doesn't have the "Select All" option which
is a mismatch from how the native Android menu works.

BUG= 615435 

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

[modify] https://crrev.com/8bf0dbc4326668e5a12f974f783e5543b78fe4f9/content/browser/DEPS
[modify] https://crrev.com/8bf0dbc4326668e5a12f974f783e5543b78fe4f9/content/browser/android/content_view_core_impl.cc
[modify] https://crrev.com/8bf0dbc4326668e5a12f974f783e5543b78fe4f9/content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
[modify] https://crrev.com/8bf0dbc4326668e5a12f974f783e5543b78fe4f9/content/public/android/java/src/org/chromium/content/browser/SelectionPopupController.java
[modify] https://crrev.com/8bf0dbc4326668e5a12f974f783e5543b78fe4f9/content/public/android/java/src/org/chromium/content/browser/input/FloatingPastePopupMenu.java
[modify] https://crrev.com/8bf0dbc4326668e5a12f974f783e5543b78fe4f9/content/public/android/java/src/org/chromium/content/browser/input/PastePopupMenu.java
[modify] https://crrev.com/8bf0dbc4326668e5a12f974f783e5543b78fe4f9/content/public/android/javatests/src/org/chromium/content/browser/ContentViewCoreSelectionTest.java

The fix made it into M59, and it should reach the Beta channel in a couple of weeks.