Plugin not working on Android 9

[apache]

Plugin not working on Android 9

[breautek]

Playing around with your app, I did find some weird behaviour...

If StatusBar.overlaysWebView(true); is called on deviceready event, then the statusbar does not go into overlay mode as expected. Trying to call it again through the console and the API call appears to do nothing. Setting it to false then true again via the console appears to correct the problem.

Additionally, if I omit the StatusBar.overlaysWebView(true); call on deviceready altogether. Then invoke StatusBar.overlaysWebView(true); via the console, it works the first time, 100% of the time.

Lastly if I do:

setTimeout(() => {
      StatusBar.overlaysWebView(true);
    }, 1000);

in the deviceready event, consistently the statusbar goes into overlay mode (after a second delay obviously).

This tells me there is some kind of asynchronous or race condition problem with the plugin.

[breautek]

I'd say there are actually two problems.

First is the one I described above. The second is overlaysWebView(true) will clear the set background colour. I don't think this is necessary. Toggling the webview overlay should remember the set background color of the statusbar.

[diamond95]

@breautek thanks, but simply now I'm trying to make that status bar transparent without any color..
I tried your update, and there is still black statusbar.

If this value is not set, the background color will be transparent.

I did not set any background color. Check updated repo please.. and thank you, really!

[breautek]

Setting backgroundColorByHexString and overlaysWebView(true) are two conflicting states and I'm pretty sure they'll override each other. (I'm wrong about this, they will not conflict)

If you want the status bar overlayed, then I would just use overlaysWebView(true).

Also, using overlaysWebView will set/unset UI flags so AndroidFullScreen.setSystemUiVisibility(AndroidFullScreen.SYSTEM_UI_FLAG_FULLSCREEN | AndroidFullScreen.SYSTEM_UI_FLAG_LOW_PROFILE); may be conflicting, but I'm not sure.

Note that right now, you must use the JS api StatusBar.overlaysWebView(true); as you are using right now. The overlay preference is broken, pending PR #142 for a fix.

[diamond95]

I tried without setting backgroudColorByHexString and its not working.
Also, I comment out AndroidFullScreen.., same problem.

So, we wait for fix or ?
Thanks for quick response

[breautek]

I need to make a correction.

Setting backgroundColorByHexString and overlaysWebView(true) are two conflicting states and I'm pretty sure they'll override each other.

I'm wrong about this, they will not conflict. You can have a status bar in an overlay state, and still set a background color to it.

Below should be all you need to set the statusbar to overlay mode. It will make the status bar transparent, and your webview will appear underneath the status bar (so padding-top may be necessary). Similar to what you had before.

document.addEventListener('deviceready', () => {
    StatusBar.overlaysWebView(true);
    StatusBar.backgroundColorByHexString('#33000000');
});

This was tested on my android 9 device, if it doesn't work for you, then please provide a sample reproduction app. Learn more about creating a reproduction app at https://github.com/apache/cordova-contribute/blob/master/create-reproduction.md

[diamond95]

padding-top did not resolve my issue.
I have created simple blank application with:
StatusBar.overlaysWebView(true); StatusBar.backgroundColorByName("red");
, where on Android 9 statusbar is >black< and on PhoneGap dev application Statusbar is >Red<.
...
After some testing: I tried to alert(Statusbar);

1. https://ibb.co/ssFfRW6
   as you can see, there is red StatusBar behind, which is ok.

After clicking OK:

2. https://ibb.co/3MgWxrj

Something wierd is happening

[breautek]

Please provide a sample reproduction app, then I can take a look at it.

https://github.com/apache/cordova-contribute/blob/master/create-reproduction.md

[breautek]

Because two issues isn't really related I've created two new issues, specifically for issues I found, #158 & #159. That way both issues can be tracked or worked on independently. You're welcome subscribe to the new issues.

In the meantime, there are two workarounds that I can foresee:

The first one as I already stated it, wrap the StatusBar APIs in a setTimeout. This is obviously very dirty and might not be reliable however, and definitely doesn't make your app look very professional.

So I'd suggest another workaround:

I would fork this statusbar plugin, and apply the #142 PR to your fork. This will fix the StatusBarOverlaysWebView preference inside config.xml and allow you to set these modes without relying on the JS APIs. This should work as when I was experimenting with your app, I copied the statusbar state to plugin native initialization to see if the behaviour changed and when doing so, your app's statusbar was working as expected.

Let me know if any of these workarounds work for you

[diamond95]

Thanks for checking out my problem!
I tried your following example with setTimeout function, and still it's same problem, not working.
When I open application on android, it automatically shows me black statusbar ( which is ok ), and after timeout for few seconds nothing have changed.
Did you change something in config.xml, which, maybe working for you?

I would like to use that solution while plugin will be fixed.

I have commited my changes. Please check it out.
Regards

[breautek]

I did change some stuff in your repo during my experimentation. I pushed my changes in a new branch on your repo.

[Akronae]

Okay I've found that using this structure works

StatusBar.overlaysWebView(false);
setTimeout(() =>
{
    StatusBar.overlaysWebView(true)
    setTimeout(() =>
    {
        StatusBar.backgroundColorByHexString('#22200000')
    }, 100)
}, 100)

Kind of stinky but it's the only way to making it work 😂
I've also noticed that when not using this technique, focusing an input field and having the keyboard getting displayed makes the status bar render as it should.

Hope this helps

[breautek]

I'm closing this issue in favour of the two issues reported at #158 and #159 to help keep things organized.

@Akronae Using timeouts like in your code snippet is a workaround to #158