I think that proposed feature makes sense for WebView as well (in other words, I do not see what would block it). I'm not sure whether we want to lock the screen without the user (i.e. a third-party Android developer) consent, in that case yet another entry in WebSettings
https://developer.android.com/reference/android/webkit/WebSettings.html
might be needed.

https://docs.google.com/document/d/1diEQn4LPwqVI72t6bYkz-Pbx1pAyf4OTNxq-2qwAbYQ/edit

Tima, if you think the developer needs to be able to control the behaviour then that means we *do* need to block this for WebView. There's two ways we usually allow developers to control behaviours like this:

1) Have the feature be disabled by default and introduce an API that turns it on in the next version of Android.
2) Have the feature be disabled by default unless the app's targetSDKVersion is "the next version of Android", and introduce an API that turns it *off* in the next version of Android.

In both cases, the "immediate" behaviour for existing apps and OS versions would be that the feature is disabled, and so the first step is to entirely disable the feature for WebView until we've implemented one or the other of those two options.

Of course, sometimes we decide that it's not necessary for the developer to control the behaviour at all, and we simply enable it unconditionally, and that's fine if we believe the compatibility risk is low. But, what we avoid is "add an API to control it in the next version of android, but have it enabled by default for all apps", because that doesn't really make sense; either it's a compatibility risk or it's not.

Torne, thank you, makes perfect sense!
Personally I like the safest option, which is (1): disable everywhere and let the user enable it with the new API. They can only do it in a new version, where such API would exist.

However, this is based on my conservative personality and not on any specific technical differences between video in Chrome vs WebView.

Mounir, Torne, would you like to add something? Or shall I close this bug?

Because screen orientation api is disabled on WebView, there is nothing specific to do here: the feature will automatically not work.