Page MenuHomePhabricator

MobileFrontend overlay toolbar can have no top border in Chrome 69 on Android
Open, MediumPublic

Description

Problem

With the latest version of Chrome on Android (69) the Chrome header and Android status bar are white by default. In some cases, e.g. when you are editing an article, there is no distinction between the bottom of the status bar and the top of our website. Previously the status bar was black by default so this wasn't an issue.

Revised solution

As @Krinkle pointed out in T204691#5752221 there is a more optimal solution available to us: adding a gray border between the top of the website and the browser header/status bar. This will solve the issue without drawing attention to the header/status bar (as the previous solution does). The border should be 1px solid #eaecf0 and should result in the following:

Previous solution

We can define a theme color in our site's manifest file so the status bar and Chrome header are no longer white. Our first choice was base90/#f8f9fa, however that color doesn't seem to be registering (our assumption is that it's too light) so we'll be going with our second choice of base80/#eaecf0 instead.

Patches exist:

QA steps

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Esanders added a comment.EditedSep 19 2018, 5:34 PM

The web manifest is only used for installed web apps, and the background color property is only used for the splash screen.

We could change the theme color in web using <meta name="theme-color" content="#..."> but that changes the colour of the search bar as well as the status bar, which seems a bit extreme.

Change 461439 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Add theme-color meta tag to Minerva

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

but that changes the colour of the search bar as well as the status bar, which seems a bit extreme.

It doesn't seem more extreme to me than adding several lines of CSS that apply everywhere except iOS. The fact the status bar is no longer black (as you mentioned it was before) seems like a regression.

@Nirzar, @alexhollender I've loaded the code on staging if you'd like to try it out on an Android phone and approve the change: https://reading-web-staging.wmflabs.org/ - this changes the address and status bar from existing white to #222.

@Jdlrobson not sure if this was intended or not, but on staging I'm seeing the status bar + the browser header as black, which is a bit intense.

It's difficult for me to tell what else is going on, because my status bar is default black when I'm using Chrome...

@Jdlrobson not sure if this was intended or not, but on staging I'm seeing the status bar + the browser header as black, which is a bit intense.

Yes, this is what I was referring to when I said "extreme", not the technical approach :)

Jdlrobson added a comment.EditedSep 19 2018, 9:10 PM

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):

FacebookYelpPinterestTwitterRedditAmazon

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

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.

Esanders added a comment.EditedSep 21 2018, 1:42 PM

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 < 69Chrome 69
Esanders renamed this task from MobileFrontend overlay toolbar can have no top border on Android to MobileFrontend overlay toolbar can have no top border in Chrome 69 on Android.Sep 21 2018, 1:52 PM

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

RHo added a subscriber: RHo.Sep 21 2018, 5:18 PM

+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

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.

cmadeo added a subscriber: cmadeo.Sep 21 2018, 9:15 PM

+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?

Esanders added a comment.EditedSep 22 2018, 11:50 AM

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.

Jdlrobson updated the task description. (Show Details)

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

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

phuedx added a subscriber: phuedx.Sep 27 2018, 10:12 AM

☝️ 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

Live on reading web staging and the beta cluster. Take your pick!

Jdlrobson updated the task description. (Show Details)Oct 1 2018, 6:55 PM

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

phuedx removed a subscriber: phuedx.Oct 4 2018, 10:36 AM
alexhollender added a project: Product-QA.

Looks great. Here are a few screenshots, including the editing view that prompted this task:

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

Moving this to QA

alexhollender removed a project: Product-QA.
alexhollender added a subscriber: Ryasmeen.

Whoops, just saw the note to skip QA. Moving to sign off.

@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.

ovasileva closed this task as Resolved.Oct 8 2018, 3:42 PM

looks good - resolving.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptOct 8 2018, 3:42 PM
Volker_E removed a subscriber: gerritbot.
Krinkle added a subscriber: Krinkle.EditedDec 18 2019, 7:59 PM

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-topno border

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 < 69Chrome 69

[…]

[current]base80accent50

[…]

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?

[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.

alexhollender reopened this task as Open.Jan 7 2020, 8:28 PM
alexhollender updated the task description. (Show Details)

Re-opening this task based on T204691#5752221. I've added a revised solution in the description.

ovasileva triaged this task as Medium priority.Feb 5 2020, 11:33 AM
ovasileva moved this task from Upcoming to Triaged but Future on the Readers-Web-Backlog board.
JTannerWMF added a subscriber: JTannerWMF.

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

matmarex moved this task from To Triage to Triaged on the VisualEditor board.Feb 12 2020, 5:23 PM

We are deprioritizing this task.

JTannerWMF moved this task from Incoming to Freezer on the Editing-team board.Mar 18 2020, 5:50 PM