In case it's the same area, no icon is displayed on the splash screen either just a title.

I can't reproduce this in Chrome Beta 59.0.3071.25. I tested pokedex.org, added it to homescreen, opened it from the homescreen, then used the search functionality. It worked fine.

Can you please provide a specific site where you are encountering this issue, or upload a screencast demonstrating what you mean?

Regarding your comment on the page not being available in the Applications drawer: that functionality is slated to launch in one of the very next releases of Chrome (either 58 or 59).

Thanks for the quick response Dominic.

Mate this is by no means a SSCCE but please go to: -
https://hypocampus.applications.uwa.edu.au (need GeoLocation on and no private browsing as localStorage is used)

After "loading" and the map is displaye, you can either: -
1) Tap the mask/anonymous icon. Username/password should appear. Sadly, along with the status bar.
2) Tape the chequered police button and then tap the email button. Again, the status bar accompanys the virtual keyboard.

HTH

Cheers Richard

PS. Great news about the 1st class Apps!!!

Thanks for the link. Just a clarification for posterity - it sets display: fullscreen in the manifest (not display: standalone like in the first comment). Using display: standalone means that the site will always have the status and navigation bars visible; display: fullscreen hides the status and navigation bars.

In my testing, the site opens in immersive fullscreen (no status bars) after adding to homescreen. The status bar appears when the keyboard is triggered. However, once the keyboard is dismissed, it hides itself again after a couple of seconds (that's the intended behaviour). I'm using a Nexus 5 with Android M and the stock Google keyboard app. I'm fairly sure that this is the usual behaviour in Android: when the keyboard appears, it will make the status bar appear as well if it's not present. We then explicitly set the system flags to make the status bar go away again once the keyboard goes away.

Can you confirm if the status bar disappears and the app looks right again after you finish with the keyboard? If that does happen, then this is working right.

PS: we're also really excited about getting added-to-homescreen sites treated as first class apps. See the beta announcement at https://blog.chromium.org/2017/02/integrating-progressive-web-apps-deeply.html and keep tuned for the launch announcement. :)

The status "bar" does in fact disappear after a couple of seconds *but* the status bar contents signal-strength, battery, clock etc remain :-(

If these were to "disappear" with the theme_colour bar then I can probably live with it but have to say that I'm not sold on the "Standard Android" connection between the virtual keyboard and the status bar. What's the relationship?

Keep up the good work!

Sorry, "Yes" when the keyboard retreats the status bar contents disappear also.

My rough understanding of the behaviour is that the Android keyboard is basically another app which is coming up in an overlay, and so it gets to decide whether or not the status / navigation bars appear or not. When it goes away we get system UI control back so we can rehide the bars.

Can you clarify that the status bar contents are disappearing properly and your app then looks okay after the keyboard is dismissed? (i.e. is there something we need to follow up on here). Just a little confused at the last two comments. :)

Yes, I have not been clear. And yes there still is something for you to fix.

Bug: - 
1) Keyboard displays and status-bar displays
2) After ~2secs status bar *background/theme-color* disappears but status-bar contents remain. The clock, battery-life etc. Is this point clear?
3) When the Virtual Keyboard retreats so does *all* remnants of status-bar

IOW your attempt to turn off the status bar is only partially effective.
  

I think the confusion may stem from a combination of the two of us using different devices and observing different behaviour and secondly a Web App developer's expectations of what "fullscreen" is.

1) While the keyboard is visible the status-bar goes from opaque to translucent after 2 secs but it leaves the content/status-icons. This fence-sitting or half-pregnant approach can not be explained away as "expected"
2) Developers, at least me, had no idea that a status bar served some magical function for the keyboard 

Strange, I have reproduced the behaviour on my mate's Nexus 5

Ah, I think this is a duplicate of another bug that we're currently looking into (where the colour of the bar itself get confused). Can you upload a screenshot of what you're seeing to confirm?

Sorry no screen shot but I'll try to be as succinct as possible. This is the observable behaviour when an <input> field receives focus: -

1) Status bar appears simultaneously with Keyboard
2) Status bar has a gray background color when manifest theme_color is white
3) After 2 secs the gray of the status bar disappears but the content/clock remains. It's like the zIndex of the status bar background goes low but the text content stays high.
4) Whenever the keyboard disappears *all* of the status bar including residual status-info disappears

Are *you* not seeing this?


Manifest is: -
{
  "short_name": "hypoCampus",
  "name": "hypoCampus Web App",
  "icons": [
    {
      "src": "icon1.png",
      "sizes": "128x128",
      "type": "image/png"
    }
  ],
  "start_url": "civitas.html",
  "background_color": "#27348b",
  "theme_color": "white",
  "display": "fullscreen"
}

Yes, I understand what you're saying now. I see the same thing. The issue isn't that the status bar is disappearing. What's happening is that its background is going transparent, rather than respecting the supplied theme colour or background colour. This is the same as another bug we're tracking, and we're hoping to have a fix in the next Chrome update.

But I hope the "fix" involves *removing all* the status bar rather than persisting the status bar for the life of the keyboard?

I've been investigating and I'm increasingly convinced that we can't actually remove the status bar while the keyboard is up. We're not doing anything to explicitly show the status bars when the keyboard is activated; and we do want to retain the ability for users to swipe it in (we're a bit constrained in the layouts we can use on the Android site because we also support the standalone fullscreen mode that always shows the status bars). Unless someone other than me can find the magic set of flags and incantations, we might be stuck having the bars show when the keyboard is up. That means we need to try and fix the transparency issue so it doesn't look so bad.

Instead, I'm going to propose that we leave the status bar color as solid black when the app is in immersive fullscreen. There appears to be a weird interaction with setting status bar colors in immersive mode and when the keyboard is showing. But setting the status back color as black and leaving it like that avoids the transparency problem and ensures the bars show up correctly. We don't really need to theme the status and nav bar when a webapp is in immersive fullscreen because they're not there by default and will only show up when a keyboard is up (which greys everything else out anyway) or if the user explicitly swipes them in to exit or use the back button.

Hi Dominic, Look I follow your work around logic and "solution" but find it hard to believe that you can control the status-bar-background opacity but not its contents/foreground. If this is to be the consistent behaviour across web apps on Android, regardless of browser, then that's fine I suppose.

Dropping the screen down status-bar-height-pixels could be good?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/675b4a3705f129ca9d31e22c42d9a785bc9bf29a

commit 675b4a3705f129ca9d31e22c42d9a785bc9bf29a
Author: dominickn <dominickn@chromium.org>
Date: Thu May 11 00:13:39 2017

Don't use the manifest brand color when a PWA is in immersive fullscreen.

When in display: fullscreen, the status and navigation bars on Android
are hidden, and can be swiped in by users if desired. The bars also
appear if the on-screen keyboard is triggered. However, the bars
sometimes appear as completely transparent, which hurts their usability.

This CL explicitly sets the status bar color to black if a PWA is launched
in display: fullscreen, and ignores the brand color specified in the web
app manifest. This ensures that the status and navigation bars always
have a solid black background and do not appear as transparent. Since
PWAs that are open in display: fullscreen have the bars hidden most of
the time, having a black color does not overly affect the native fit and
feel too much.

BUG=714704, 716686 

Review-Url: https://codereview.chromium.org/2871103002
Cr-Commit-Position: refs/heads/master@{#470762}

[modify] https://crrev.com/675b4a3705f129ca9d31e22c42d9a785bc9bf29a/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappActivity.java

FYI, Just as a side note Chrome on android does not ask for Geolocation permission any more. (Since when? Not sure which version)

This is after clearing history rebooting etc. 

Just thought you should be able to reproduce easily? Same site on Windows desktop requests permission.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8fc052bc58d3adbc8c6f6e13109da6e733f8ee20

commit 8fc052bc58d3adbc8c6f6e13109da6e733f8ee20
Author: Dominick Ng <dominickn@chromium.org>
Date: Mon May 22 03:49:33 2017

Don't use the manifest brand color when a PWA is in immersive fullscreen.

When in display: fullscreen, the status and navigation bars on Android
are hidden, and can be swiped in by users if desired. The bars also
appear if the on-screen keyboard is triggered. However, the bars
sometimes appear as completely transparent, which hurts their usability.

This CL explicitly sets the status bar color to black if a PWA is launched
in display: fullscreen, and ignores the brand color specified in the web
app manifest. This ensures that the status and navigation bars always
have a solid black background and do not appear as transparent. Since
PWAs that are open in display: fullscreen have the bars hidden most of
the time, having a black color does not overly affect the native fit and
feel too much.

BUG=714704, 716686 

Review-Url: https://codereview.chromium.org/2871103002
Cr-Original-Commit-Position: refs/heads/master@{#470762}
Review-Url: https://codereview.chromium.org/2900593003 .
Cr-Commit-Position: refs/branch-heads/3071@{#646}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/8fc052bc58d3adbc8c6f6e13109da6e733f8ee20/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappActivity.java

c#20: you have to access the site over HTTPS in order to be allowed to prompt for geolocation. If possible, you should redirect HTTP navigations to HTTPS to ensure that you're able to get location.

Dominic, you tried the httpS://hypocampus.applications.uwa.edu.au link from
the original bug report didn't you? Something wrong with the certificate?
Cheers Richard

PS. None of the Android UAs (Chrome, Android browser, Opera or Firefox)
show the Location icon in the status bar anymore.

And the other pertinent information is that the very same site on Chrome 58 on Windows 10 DOES ask for permission and DOES show the location tracking icon in the URL bar.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8a7c6e83044807f68c5ee95321f2d72abc6d8caa

commit 8a7c6e83044807f68c5ee95321f2d72abc6d8caa
Author: amineer <amineer@chromium.org>
Date: Mon May 22 20:52:14 2017

Revert of Don't use the manifest brand color when a PWA is in immersive fullscreen. (patchset #1 id:1 of https://codereview.chromium.org/2900593003/ )

Reason for revert:
Breaks build

../../chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappActivity.java:621: error: cannot find symbol
        if (mBrandColor != null && mWebappInfo.displayMode() != WebDisplayMode.FULLSCREEN) {

Original issue's description:
> Don't use the manifest brand color when a PWA is in immersive fullscreen.
>
> When in display: fullscreen, the status and navigation bars on Android
> are hidden, and can be swiped in by users if desired. The bars also
> appear if the on-screen keyboard is triggered. However, the bars
> sometimes appear as completely transparent, which hurts their usability.
>
> This CL explicitly sets the status bar color to black if a PWA is launched
> in display: fullscreen, and ignores the brand color specified in the web
> app manifest. This ensures that the status and navigation bars always
> have a solid black background and do not appear as transparent. Since
> PWAs that are open in display: fullscreen have the bars hidden most of
> the time, having a black color does not overly affect the native fit and
> feel too much.
>
> BUG=714704, 716686 
>
> Review-Url: https://codereview.chromium.org/2871103002
> Cr-Original-Commit-Position: refs/heads/master@{#470762}
> Review-Url: https://codereview.chromium.org/2900593003 .
> Cr-Commit-Position: refs/branch-heads/3071@{#646}
> Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}
> Committed: https://chromium.googlesource.com/chromium/src/+/8fc052bc58d3adbc8c6f6e13109da6e733f8ee20

TBR=dominickn@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=714704, 716686 

Review-Url: https://codereview.chromium.org/2893413002
Cr-Commit-Position: refs/branch-heads/3071@{#657}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/8a7c6e83044807f68c5ee95321f2d72abc6d8caa/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappActivity.java

Can you please file a separate bug with separate reproduction steps (after clearing browsing data) for the permissions case. It's getting confusing with both issues in this bug.

Done. https://bugs.chromium.org/p/chromium/issues/detail?id=725348

Please note for this bug that, on Opera (but they use your UI?), after permission is requested the status bar is displayed and remains :-(

Arrrgh! when the keyboard is displayed the status bar appears and is made permanent. (Again Opera)

Please don't reproduce this!

Going to mark this as addressed for now - the transparent bars should now be gone and be replaced with solid black ones when the user swipes them in while in fullscreen. As before, they'll disappear after a couple of seconds.

Thanks mate!