Tested the issue in WebView and could reproduce the issue. Able to add the Window.

Steps Followed:
1. Installed Web Video Caster
2. Able to add the Window.

WebView versions tested
63.0.3239.111

OS
Android 6.0.1

Android Devices
6.0.1; SM- G920IF Build/MMB29K

@carlos: Could you please help us with a screencast if this issue has nothing to with adding the tabs, and also attach the details of your device for further triaging of the issue.

Thanks!!

There's two likely causes of this which would both indicate bugs in your application.

Depending what the root cause actually is, you may be able to reproduce this by loading a test page which calls one of the JS dialog functions, such as alert() or confirm().

One cause is if you are using an unusual Context object for the WebView - if you're using something other than an Activity as the Context to construct the WebView then certain functionality doesn't work. We generally try to detect this and avoid calling codepaths which will crash, but sufficiently weird ContextWrapper objects can confuse the logic, and this isn't really supported in general.

If you're already using a normal Activity context for the WebView (which will be the case if you simply have a WebView in a layout XML that you inflate, or if you construct the WebView object as "new WebView(this)" from an activity's onCreate), then another possible cause of this that you may want to investigate is the following sequence of events:

1) A WebView is associated with an Activity and displayed, and loads some web content
2) The Activity is closed (e.g. by finish()) and onDestroy is called and completes, deleting the Activity's associated Window.
3) The Activity and WebView are now unreachable and eligible for garbage collection, but aren't destroyed immediately (only when the next GC happens).
4) The JS code in the web content in the WebView calls confirm(), resulting in a callback, and the default callback implementation fails because the Activity's window has been deleted, resulting in this crash.

This particular sequence of events can be avoided by properly destroying the WebView in the Activity's onDestroy implementation: detach it from the view hierarchy, call the destroy() method on it, and null out references to it that may be stored in the Activity. This will stop any further JS execution in the WebView at the next possible opportunity, ensuring that no more callbacks occur after the window is destroyed.

If you're already explicitly destroying the WebView at the expected time, then we would need more information about how your app uses WebView to guess what the cause might be.

Unfortunately I have never seen this issue myself so I don't have screencasts or even know when it happens. 

As far I can tell all my WebViews use the Activity Context and I have calls to destroy but I'll review all my code to make sure I didn't miss something. 

I am curious though, I override the JS Confirm, JS Alert, and JS Prompt dialogs. This exception seems to be for a JS Confirm. Would this even happen if the dialog is being shown by my own code? I'm wondering if that means the error is maybe with some interstitial ad that shows a JS Confirm. 

Thanks. 

The stack indicates that this is a case where you haven't overridden the dialog and the default implementation is being used, so yes, this might be coming from an ad SDK or similar that you are using and not your app's own code. Possibly the ad doesn't destroy its webview properly?

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The recent spike could be the accessibility bug that was causing webviews to leak if accessibility was turned on. The good news is we've fixed that leak, and we've also decided to catch this exception and turn it into a warning instead of crashing. So this problem should go away soon.

Ok, thank you for that information. Hopefully I'll get to reproduce the issue some day and then I can report it to the right ad network. 

Closing based on #3 and #7.