It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@bparrishMines @dnfield Same here; still needs tests, but I would appreciate feedback.

I have concerns about the fundamentals of the create/resize logic code here for TLHC (i.e., I suspect there are more subtle race conditions that are still latent here that this change neither fixes nor worsens), but wanted to limit the scope here since I am still hoping to get this onto beta.

This also fixes a 3.0 regression found during manual testing, where create is sometimes called multiple times: once by the plugin author, but then again by internal code that was only intended to be used for TLHC and VD, but due to the async nature of the initialization, was being called for HC as well. Because some plugin authors have noticed the double-call bug and worked around it by removing their create, we can't actually directly fix the double-create without more extensive changes (unless we re-break plugins that worked around the 3.0 bug), so for now this drops duplicate calls, and leaves TODOs for fixing it more cleanly.

With more investigation, it looks like this is actually a 3.1+ regression, so I'm going to split it out into its own fix. It's a new regression that only affects beta, and it severely breaks HC mode, so should be fixed and cherry-picked separately. (I was hoping to avoid layer fixes and cherry picks, but this seems critical enough to take that risk.)

This still needs widgets tests for the new switching widget, but I think it would be worth reviewing now to see if that approach is in fact what we want before I implement the tests for it.

I have a small question. After this gets merged what would be the breakdown of modes?

• initSurfaceAndroidView -> TLHC, but can fallback to HC when SDK <23
• initAndroidView -> TLHC, but fallback to VD when SDK <23
• initExpensiveAndroidView -> always TLHC (?)

What would be used by default by AndroidView?

• initExpensiveAndroidView -> always TLHC (?)

This PR doesn't change the behavior of initExpensiveAndroidView. It continues to always use HC.

What would be used by default by AndroidView?

This PR doesn't change the behavior of AndroidView, which calls initAndroidView.

(triage): @stuartmorgan do you still have plans for this PR?

I'll be updating it shortly to be landing-ready; the engine side just landed.