This is not a security bug, removing labels.  +sgurun and sievers@ -- Can you assign an appropriate component?  Thanks.

the way to do this is by overriding onprovidevirtualstructure. you can even  provide a custom virtual structure if desired.

https://developer.android.com/reference/android/webkit/WebView.html#onProvideVirtualStructure(android.view.ViewStructure)

Selim, I don't think that's relevant. There's several different ways to control the data that the view hierarchy provides to Now on Tap, and setting FLAG_SECURE is one of them, which disables inspecting the view hierarchy for the affected window entirely.

In this case, however, the assistant is *not* inspecting the view hierarchy at all. The options on the text selection menu are explicit actions that send the selected text (and nothing else) to things that have configured a suitable intent for text processing, and the assistant is one of them. Since the user is explicitly sending the selected text to the assistant, it seems like FLAG_SECURE isn't relevant as the assistant is not probing into the application's views.

WebView does not do anything specifically to provide the assist option here - we just include all text processing actions defined on the device, and we have no idea what they mean (we use the labels provided by the intents that match the filter). There's not really a sensible way for WebView to have a special rule about disabling one particular text processing action in the case where the window is FLAG_SECURE. What's the behaviour of TextView here? It includes text processing actions in the context menu in the same way, and so I would expect it to behave the same. If TextView is filtering this out when in a secure window then WebView should probably copy it, even if this is a weird special case, but if TextView also allows this then we're unlikely to change the behaviour.

In N, we are adding an API which allows you to disable all text processing actions (and also the web search/share options) in the text selection menu: see the N preview release docs for WebSettings.setDisabledActionModeMenuItems - however, this won't help you on M devices. :/

Selim, I agree with @torne's comments. I'm glad to see this is addressed in N, but unfortunately this doesn't help with our situation with Marshmallow. The current behavior also has an additional adverse side affect. Our app is also pinned, and is used in a testing environment. Searching is essentially blocked since the user can't leave the app, but you can ask questions "OK Google, what is 4 + 4" and you will get an answer. Typically this wouldn't be a problem either but our app is used for high-stakes testing, and essentially a user could get most answers with "OK Google, ..." 

Does TextView do anything special here? If not, then we aren't likely to change this in WebView either. If TextView somehow disables it, we should look into that and imitate what it does.

@torne, we only use a webview, the text field is inside of the webview

Right, but what I'm saying is that we aren't going to change the behaviour of WebView here unless it's inconsistent with how other editable fields (like TextView) behave in Android. I don't think TextView does anything different here, but I haven't tested this.

@torne, you are correct. It behaves the same way as other editable fields. The only way to disable is to create your own assistant, which replaces the global assistant :(