Okay, some wires got crossed then :). I thought @Nirzar had approved the black color... :) anyway... that black can be changed to anything we want. As long as it's not #fff i believe it solves this issue in best way possible.

Here is a theme colour of #eee:

The color theme of #eee looks good to me. It seems like the standard practice is to make the status bar a darker version of the color used for the header, would that be possible? As in:

Here are how a few other people are handling it (some are doing custom colors, others aren't):

Facebook	Yelp	Pinterest	Twitter	Reddit	Amazon

Change 461694 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Default theme color is #eee

https://gerrit.wikimedia.org/r/461694

If I understand @alexhollender's last comment correctly, some of the sites (Facebook, Yelp, Pinterest) use not one, but two of their brand colors. #eee is not part of our color palette, I'd consider #eaecf0, see https://design.wikimedia.org/style-guide/visual-style_colors.html#base-colors

#eaecf0 is live on https://reading-web-staging.wmflabs.org/

Sorry to delay this, I realize we're eager to get a fix out. I'm just going to run some options by Nirzar, which I will also post here, and should have a resolution tomorrow.

It seems like the standard practice is to make the status bar a darker version of the color used for the header, would that be possible? As in:

They're not doing this by choice - that was automatic behaviour prior to Chrome 69 which is why this is a new issue. There is only one colour you can specify, and Chrome generated the darker status bar itself. Since Chrome 69 the address bar and status bar are identical, and the default for the status bar is white, not black.

Chrome < 69	Chrome 69

Here it is with a theme colour of #eaecf0, as suggested by Volker:

Thanks for the clarification about what is possible @Esanders. This might seem like overkill but I want to consider all of our options here:

default (if we do nothing)
accent50
base90
base80
base30
base20
base10
base0

@Nirzar @Volker_E

base 90 works, doesn't take too much attention and focuses on our content

+1 to Base90

+1 to Base90
FWIW in the next release of the Wikipedia Android app, we are updating the toolbar to use Base90 everywhere (see T197812):

Explore feed

Article view

Ok great, @Esanders or @Jdlrobson let's go with base90 (#f8f9fa).

Thanks

https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/461694 is ready for review.

I don't think this example matches what is happening in VE. There is a single pixel border above the toolbar, which isn't present in my screenshots. The original issue was that there was no delineation when there was no border.

In fact on my local environment, it appears to ignore base90 as being too close to white, and leaves the header bar as white.

+1 to Base90, but also a point against Accent50 is that Android will be removing the blue highlight from the feed soon

There is a single pixel border above the toolbar, which isn't present in my screenshots

Can we add a border?

In fact on my local environment, it appears to ignore base90 as being too close to white, and leaves the header bar as white.

hmm, not really sure what to do about that? Maybe we can try slightly increasing the darkness until we find the threshold?

Can we add a border?

If we add a border, then we don't need to bother with the theme colour. Also on OSes that do have borders you will have a double border (this is the reason I went with an inset shadow in my original patch).

We either need to use something that works with or without a border line draw by the OS (e.g. an inset shadow), or a darker theme colour that provides enough contrast to white i.e. closer to the border line colour.

Jon and I sat down yesterday and tried to figure out if there was a color close to base90 that would register. Turns out you have to get pretty close to base80 in order to get it to take, at which point it kinda just looks weird because it's just a shade lighter than our Wikipedia header. So after all we will move forward with the option @Esanders posted here T204691#4605772.

Change 461694 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Lighten default theme color

https://gerrit.wikimedia.org/r/461694

☝️ I moved this task onto the board because it's been worked on by @Jdlrobson and @alexhollender. It looks like it's ready for signing off on too… Have I misunderstood the state of the task?

Two patches remain open. I'm happy to get https://gerrit.wikimedia.org/r/461439 reviewed but will lean on @Esanders and his team to confirm this resolves this bug.

Change 461439 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Add theme-color meta tag to Minerva

https://gerrit.wikimedia.org/r/461439

Change 461116 abandoned by Jdlrobson:
Add inset shadow to overlay header on Android

Reason:
lemme know if this is the wrong action!

https://gerrit.wikimedia.org/r/461116

@Jdlrobson I'm not sure if this is relevant, however oddly the new status bar & chrome header color are inconsistently present on production:

Expected. HTML caching. It will not happen in about a week's time.

In T204691#4607938, @Esanders wrote:

In T204691#4607334, @alexhollender wrote:

Can we add a border?

If we add a border, then we don't need to bother with the theme colour. […]

While it is true that the a border-top for browsers other than Chrome/Android may result in a double border in combination their their native divider, this tends to blend well and appear as one or as slight inset. Nearly invisible to the user. For example:

1px border-top	no border

In T204691#4605734, @Esanders wrote:

It seems like the standard practice is to make the status bar a darker version of the color […]

They're not doing this by choice - that was automatic behaviour prior to Chrome 69 which is why this is a new issue. […]

Chrome < 69	Chrome 69

In T204691#4606271, @alexhollender wrote:

[…]

[current]	base80	accent50

[…]

I believe the reason the default may have changed in Chrome is to give a more native feel to the reading experience. In particular, I associate reading on the web with poor UX on websites that have headers and footers that don't scroll out view but permanently block out part of the screen. This gives, I think, a sense of a crammed viewport.

Darkening the header in this way means the top of the screen no longer blends out of mind with the top of the page when reading. Rather it prominently stands out and actively shortens the perceived length and freedom of the viewport.

I am curious whether you share this perception and consider this darkening a compromise or a universal improvement you would have considered even without this task for the reading experience.

If not, then perhaps the border suggestion that was initially used in the mockup is worth considering?

In T204691#5752221, @Krinkle wrote:

[clipped]
I am curious whether you share this perception and consider this darkening a compromise or a universal improvement you would have considered even without this task for the reading experience.

If not, then perhaps the border suggestion that was initially used in the mockup is worth considering?

@Krinkle Thank you for raising this question. Looking back over the comments I'm not entirely sure why we didn't consider trying to implement the border approach. I agree that the browser header and status bar with a white background and a border below is preferable to what we currently have.

Who has ownership of this task is it Readers Web or Editing? @ovasileva

We are deprioritizing this task.