We're experiencing this bug in Basecamp 3 Android app. Devices on Chrome 64 with any accessibility service (TalkBack, password manager autofill, etc) enabled experience the crash. 

We use a shared (and sometimes offscreen) WebView that is swapped between activities using our Turbolinks Android library https://github.com/turbolinks/turbolinks-android. 

We remove the shared WebView from the layout of an Activity that is exiting. We then insert the WebView instance into the incoming Activity layout on screen.

To work around the crash, we've added the following code to our app:

try {
    // Often throws exception with:
    // IllegalArgumentException: Receiver not registered: org.chromium.content.browser.accessibility.LollipopWebContentsAccessibility$1@1a696f8
    // at org.chromium.content.browser.accessibility.LollipopWebContentsAccessibility.onDetachedFromWindow(LollipopWebContentsAccessibility.java:42)
    layout.removeView(webView)
} catch (e: Exception) {
    // Actually removes the WebView from the exiting Activity layout
    layout.removeView(webView)
}

The is the related code change between Chrome 63 and 64 that has caused the exception to be thrown:
https://chromium.googlesource.com/chromium/src.git/+/05d9038e765025cca1f8933fe4cf120c038fa2eb%5E%21/content/public/android/java/src/org/chromium/content/browser/accessibility/LollipopWebContentsAccessibility.java

Potentially related: https://bugs.chromium.org/p/chromium/issues/detail?id=808751

Looping to committer of the cl mentioned in #2.

Stop using ContextWrapper to change the underlying context. Webview is not doing anything illegal here, and it's the app's problem that it's changing the underlying Context object while webview is using it.

Note catching the exception is not the correct fix and may lead to memory leaks.

Yeah, don't swap WebViews between activities in the first place - there's no way to do that which is guaranteed to work, and there have been many issues in the past with apps that try to do this. Each WebView should be associated with a specific Activity which it uses as its context, and that's all.

Hi, a couple questions...

1. The original poster noted correctly that the `mContext.registerReceiver()` is wrapped in a try/catch, but the `unregisterReceiver()` call is not wrapped in a try/catch. If the context was never originally registered because an exception was caught during registration, wouldn't this still throw an exception when unregistering? I'm hoping this can be addressed separate from comments 5 & 6, which are more around swapping contexts (addressed further in #2 below).

2. Separate from #1, isn't changing the webview's context object a legal operation? I understand that from experience this may have caused issues in other places you've seen. But WebView.context() can be referenced as type MutableContextWrapper, which seems to imply that contractually it's OK to change the base context of the webview if you like. In that regard, it doesn't seem like we're violating the webview contract by swapping its context object.

Thanks for your help on this!

1. that's not the case here. plus ignoring exceptions is a bad idea. if you ignore the exception in unregisterReceiver here, then it might very well lead to massive leaks

2. no that's not legal. just because an API exists, does not imply it's safe to do. you have to know what you are doing. for this to work correctly, you'd need like a webview.setContext api to change it, not just silently change it from underneath webview and expect things to magically keep working

Also, I'm not sure what you mean by "WebView.context() can be referenced as type MutableContextWrapper" - there's no context() method, and WebView.getContext() returns a Context. There's nothing to do with MutableContextWrapper anywhere in the WebView API, so I don't see where your assumption is coming from.

Gotcha, #2 makes sense. We'll look into how to better handle this.

Any chance you could further explain #1's "that's not the case here"? Is it that if the broadcast receiver isn't registered in the first place, that would be considered an unexpected state and unregistering *should* throw an exception? Or is the unregistration just ignored?

Thanks.

I'm just saying registerReceiver did not throw an exception (that was then ignored), the problem is the underlying object changed between register and unregister.

From webview's perspective, registerReceiver succeeded, so it should be legal to call unregisterReceiver with the same receiver object and expect it to succeed as well.

@torne That's fair. It's possible we're making a poor assumption based on something we derived early on during our library development and never re-visited. 

Our library fundamentally relies on a long-lived WebView that's shared between activities. I totally understand that's not entirely intended and we're going against the grain a bit, but we're trying to do the best with what we have. 

Thanks for the help!

Yeah, you simply shouldn't do that. :) Views belong to view hierarchies which belong to activities. The platform in general does not expect *any* view to be moved between activities; WebView is not the only thing that will break in this way.