This is really strange. I can repro this on M61.

For what it's worth, I think you can work around it by moving the call to WebSettings#setJavaScriptEnabled() earlier (I can't think of a good reason not to do so.

Nonetheless, this sounds to me like a bug. I'll try to investigate more this week or next, so I'm self-assigning.

This is indeed weird but I think this is just a timing issue in an unsupported 
order of operations. You're waiting for onPageFinished, and loading different content is going to change the timing of how long that takes.

The order of operations with JS interface injection has always been significant (since it doesn't take effect until after a navigation) - I don't think it's particularly surprising that trying to enable JS after the fact doesn't work reliably, and I think it's just a fluke of timing that it works in the case without the <img> tag.

Enable JS first, before calling addJavascriptInterface or navigating.

I agree it's really an edge case, but I have been able to reproduce this with all sorts of long and short html content. The key difference was just adding a single <img> would cause the Java object to not get injected into the DOM.

<img> typically involves an external resource (even though yours doesn't), and so I can believe that is specifically going to delay onPageFinished as that waits for external resource loads to complete.

As I said, the surprising thing here is that it works in *any* case, not that it doesn't work when you have an <img> :)

torne@, would a documentation change be in order for addJavascriptInterface?

These orders *seem* ok:

 * setJavaScriptEnabled, addJavascriptInterface, loadData
 * addJavascriptInterface, setJavaScriptEnabled, loadData

While this order is bad:

 * addJavascriptInterface, loadData, setJavaScriptEnabled

For simplicity, we could just say that setJavaScriptEnabled should always be called before addJavascriptInterface, and not promise anything for other orders.

I resolved this by adding a note in the docs for addJavascriptInterface. I changed the code example to specifically call WebSettings#enableJavaScript() as well as mentioning this in the text of the docs.

Nothing to verify here, we just have to wait a long time (best guess is ~1 year) until the public docs get the update.

Bulk edit: marking stale 'fixed' bugs as 'verified' since they don't need verification at this point.