Able to reproduce the issue using WebView version #61.0.3163.98. Observed the Default menu items Copy, Paste share ,web search are getting added to custom menu items.

This seems to be a regression issue as issue is not observed in system update #58.0.3029.125. 

While bisecting (installing older M59, M60 builds) the issue Uworld SAT is application getting Crashed. Hence cannot provide the bisect.

Requesting someone from WebView team to please look into this issue.
 
Issue is seen in M63 as well.

Thanks!!

video + bugreport/logs please

Hi, I have created test application to reproduce the webview issue(Please check attachment). It replicates our webview and actionmode implementation. Please feel free to access it and modify to provide solution. Also I have attached video that shows mentioned issue. 

Deleted: app-debug.apk 1.5 MB

app-debug.apk 1.5 MB Download

Deleted: 20171002_104141[1].mp4 1.2 MB

	20171002_104141[1].mp4 1.2 MB View Download

hi, Please find attached source code of above test application.

Deleted: WebViewTestApplication.zip 21.7 MB

WebViewTestApplication.zip 21.7 MB Download

Re-tested the issue with the above mentioned test file, still the test application is getting crashed on older M59, M60 Builds. Hence unable to find the regression range.

Please find the log's and video's (Both Repro and Crash) of the issue-- here
go/chrome-androidlogs/769974-

Thanks!!

Hi, I tested on 59.0. I couldn't find any crash, also I could not reproduce issue in this version. Please check attached screenshot.

Requesting to you please provide the fix as soon as possible.
Thanks.

Deleted: Screenshot_20171003-154123[1].png 158 KB

	Screenshot_20171003-154123[1].png 158 KB View Download

Shimi, perhaps selection related? Can you see if this is still an issue on the latest WebView?

I believe the problem is that when the selection is extended we invalidate the action mode. When we do the invalidation we re-populate the menu and add back the items that were previously removed. You can get around this by overriding View.startActionMode() and passing in your own callback.

Hi, I already tried above work-around of passing my own callback. But I still see floating default copy and selectall options. Please see attached videos and source code. 

However I was able to remove Share and Websearch using webview settings:
webView.getSettings().setDisabledActionModeMenuItems(WebSettings.MENU_ITEM_SHARE + WebSettings.MENU_ITEM_WEB_SEARCH);

Requesting you please prioritize and provide solution as soon as possible as our product release is getting delayed due to this issue.

Deleted: MainActivity.java 5.1 KB

MainActivity.java 5.1 KB View Download

Deleted: Callback_ActionMode_Primary[1].mp4 730 KB

	Callback_ActionMode_Primary[1].mp4 730 KB View Download

Deleted: Callback_ActionMode_Floating[1].mp4 1.5 MB

	Callback_ActionMode_Floating[1].mp4 1.5 MB View Download

I think you misunderstood what I meant by overriding startActionMode(). I meant for you to subclass android.webkit.WebView (let's call the subclass MyWebView) and override the startActionMode() methods there. Then in your xml layout instead of having a WebView element you'd have a MyWebView element.

I tried above solution but still not able to resolve the issue. Please find attached source code.
Please feel free to modify the source code if you know the solution.

Deleted: WebViewTestApplication.zip 21.6 MB

WebViewTestApplication.zip 21.6 MB Download

amaheshwari@, please find the attached example.

Deleted: WebViewTestApplication.zip 2.0 MB

WebViewTestApplication.zip 2.0 MB Download

Hi, thank you for workaround, above solution works for us.
But is this issue going to fixed in future release?

changwan@, It seems we regressed a way some apps, such as the one in this crbug,  used to change selection menu items, the reason is mentioned in #9.

There is another way to do so in the example I was given in #13 though. I am not sure if we need to support the old way actually, it doesn't make sense to me to just add a listener and overriding action mode related APIs in Activity level either.

Could you pinpoint the regressing CL?
If this issue does not happen on a native textview/edittext, I tend to think that it is a regression that needs fixing. amaralp@, could you check how the textview avoids this issue?

There is a similar problem with TextView - the "Select All" option is still available even after the first long-press. The issue is that what menu items are shown depend on the selection so whenever the selection changes the action mode is invalidated and the menu items are reset.

amaheshwari@, is there an issue with ctzsm@'s suggestion? That is the way many WebView apps customize the action mode. 

amaralp@, Callback2 is supported from API 24 and above.
Our app support starts from API 19 and above. So we had to override both callback and callback2 action modes. This solution works for us.

But if this issue is really a bug, then can we not fix it for future release so we don't have to override all callbacks?

This issue isn't a bug. You would have a similar problem in TextView (the "Select All" option would be present). The problem is that when a selection changes the menu items might also change so we re-create the entire menu when an invalidation occurs. Please go ahead and override both callbacks on your future releases. Thanks!

 Issue 774372  has been merged into this issue.