I see this on a Pixel 2 using the kinoseed app.

Tested the issue in Android and able to reproduce the issue. Similar behavior is observed since Android WebView #58.0.3029.83

Steps Followed:
1. Install the Kinoseed application from playstore.(https://play.google.com/store/apps/details?id=com.kinoseed.matchcolor)
2. Launch the application.
3. Tap on the color picker.
4. Select any color.
5. Observed that system menu bar never dismissed and is displayed always until user exits the application.

WebView versions tested:
58.0.3029.83, 64.0.3282.140(Stable), 66.0.3344.0(Canary)

OS:
Android 7.0.0

Android Devices:
SM-J710F/ Build/NRD90M

This seems to be a Non-Regression issue as same behavior is seen since M59.  Untriaged for further input's on this issue.

Please navigate to below link for log's and video--
go/chrome-androidlogs/811213

I had a look yesterday, it looks like our ColorPickerDialog [1] isn't preserving fullscreen flag.

My guess is we might want to refactor it from AlertDialog [2] to DialogFragment [3].

I also tried this in Chrome and WebView Shell, it doesn't repro with JavaScript triggered fullscreen mode.

There isn't a clear owner of this part of code though, cc'ing native side OWNERS.


[1] https://cs.chromium.org/chromium/src/components/web_contents_delegate_android/java/src/org/chromium/components/web_contents_delegate_android/ColorPickerDialog.java
[2] https://developer.android.com/reference/android/app/AlertDialog.html
[3] https://developer.android.com/reference/android/support/v4/app/DialogFragment.html

yeah I guess that makes sense by itself, but the bigger problem is really android doesn't hide the controls again after going back to the fullscreen window

I guess my question is whether Android should.  I thought it was the requirement of the app to reapply all of it's fullscreen flags in onWindowFocusChanged.

https://developer.android.com/training/system-ui/immersive.html#nonsticky

"""
Implement onWindowFocusChanged(). If you gain window focus, you may want to re-hide the system bars. If you lose window focus, for example due to a dialog or pop up menu showing above your app, you'll probably want to cancel any pending "hide" operations you previously scheduled with Handler.postDelayed() or something similar.
"""

kinoseed@, could you please try the way we suggested in #6.

I will give the suggested workaround a try, but suggesting that it is "working as expected" is ridiculous.

You have an app with a "webview", in which a "color picker" makes the whole app lose focus?

Force showing the bars (even for file selection) damages the UX (even if they do get hidden later).
The result kills the integration of webview / PWA, and results in poor UX.


I'll give the workaround a try, but maybe you shouldn't leave it there.

The workaround does the job. Thanks.

However, as noted above, it seems like this is a side effect design flaw leading to UX issues for webview / PWA integration.

If it's not a "bug" can it be moved to "requests", or the proper category for this case if it exists. Thank you.

So according to #6, android clearly thinks keep updating fullscreen state is individual window's responsibility, ie app's responsibility in this case. We could make the app developer's job easier, but there are a lot of dialogs in webview, but it's a lot of effort for not much gain. So in reality this will never bubble up to anyone's top priority.

We accept patches though, if you want to do it yourself.

@boliu, I understand that admitting there is a design flaw is hard to do, and a "color picker" should have not triggered "system bars" (or making the app lose focus in first place).

Would a patch overriding the showing of system bars (when apps lose focus be acceptable)?

If not, where would be the proper place to request better integration of WebView?

Webview throwing up a dialog is pretty standard. The fact that dialog does all of these weird things that apps then have to correctly handle dialogs is the design flaw and unfortunate. But it's not a huge burden.

> Would a patch overriding the showing of system bars (when apps lose focus be acceptable)?

That's in your app code, not webview code right?

@boliu, showing the system bars is triggered by webview/os, correct?
Is there a way to block it?

With apps you can only handle the aftermath and re-close the system bars, just like the given workaround here, correct?

If there's a way to block the system bars from showing will be best, and should be standard to allow for better UX. 

Right now the second there's something simple like a "color picker" the whole navigation and system bars shown over the app.

Yeah, all correct. There is no way from the app to block system bars in other dialogs.

Again, we accept patches.