Hamburger icon (U+2630 TRIGRAM FOR HEAVEN) is always black on Samsung Galaxy S Android devices

[jprinaldi]

OS: Android 6.0.1 SM-G920F Build/MMB29K
Browser: Chrome 51.0.2704.81

The Bootstrap 4 navbar hamburger icon is always black, even when using other background colors such as bg-inverse or bg-primary.

The bug can be reproduced by accessing this bin:
https://output.jsbin.com/hiyeti/3

EDIT:
I just realized this behavior is present even without Bootstrap:
https://output.jsbin.com/wovuba/1

Probably an Android/Chrome issue then, though not sure if anything should be done about this on Bootstrap's side.

EDIT 2:
Here's a screenshot:

[cvrebert]

Unfortunately I don't have an Android 6 device handy, but testing in Android 5.1 via Sauce Labs shows that it does use the correct color there (but seems to lack the glyph in question).

I highly recommend that you open a Chrome bug about this via https://crbug.com/new

[anantoghosh]

Works fine for me.

[patrickhlauke]

both jsbin examples (with and without bootstrap) WFM in Chrome 51 / Android 6.0.1 on Nexus 5, including loading the correct glyph. don't think it's a bootstrap issue per se.

[jprinaldi]

I asked a friend with the same phone (Samsung Galaxy S6) and the icon is black for him as well.

Seems to be an issue with that phone then.

[Starsam80]

I can't reproduce.

[tomlutzenberger]

I actually can reproduce on Galaxy S5.
If needed, I can do some USB-Debugging.

[acshef]

I also have black bars (like @tomlutzenberger) with a Galaxy S5 (SM-G900T) on Kit-Kat 4.4.2, Chrome 51.0.2704.81

[TheBuzzer67]

Same issue, have the same problem with S7 on 6.0.1 SM-G930W8 and Chrome 51.0.2704.81 and Chrome Dev 53.0.2782.9

I just try the second code without Bootstrap, the bars are black but the background is white in both, dev and none dev Chrome version!

[cvrebert]

@juampi @TheBuzzer67 @acshef @tomlutzenberger
Please re-test using the Dev version of Android Chrome: https://play.google.com/store/apps/details?id=com.chrome.dev

[patrickhlauke]

So a Chrome/Samsung issue then? (I have 51.0.2704.81 on Android 6.0.1 on a Nexus and don't see it)

[tomlutzenberger]

I can't reproduce on Chrome 51.0.2704.103 m under Win 7.

[cvrebert]

@tomlutzenberger Yes, we've established that this is Android-specific (and potentially Samsung-specific).

[cvrebert]

@patrickhlauke Also, the glyph not rendering on Android 5.1 is a (separate) problem, since we currently claim support for Android v5.0+.

[jprinaldi]

Still shows black on Chrome Dev 53.0.2782.9 and Android 6.0.1 SM-G920F Build/MMB29K.

[tomlutzenberger]

@cvrebert Same result as @juampi

[acshef]

Still black with Chrome Dev 53.0.2782.9 on Android 4.4.2 Galaxy S5 (SM-G900T). And for what it's worth, I also tried disabling the pre-installed Chrome Samsung Support Library (although honestly nobody knows for sure what that does).

[Starsam80]

It might be a font issue. Since I can't test anything, somebody should try switching fonts and see if that helps. It might not, but it's worth a try.

[cvrebert]

Yeah, that sheen on the ☰ character is weird. Maybe Samsung has some unusual default font that uses emoji-ish rendering where the color is baked-in.

@tomlutzenberger Since you offered, could you please USB debug and inspect to see what font it's using? The panel is at the bottom of the "Computed" tab of the "Elements" inspector:

[cvrebert]

Just to summarize the data y'all have contributed so far, the bug has been observed on:

• Devices
  • Samsung Galaxy S7
  • Samsung Galaxy S6
  • Samsung Galaxy S5
• Chrome
  • 53.0.2782.9 (dev)
  • 51.0.2704.81 (stable)
• Android
  • 6.0.1; SM-G930W8
  • 6.0.1; SM-G920F Build/MMB29K
  • 6.0.1; SM-G900F Build/MMB29M
  • 4.4.2

[acshef]

Screenshot from the GMail app with @cvrebert's reply to this issue. Our culprit makes an appearance again! Definitely smells of "emoji-ish rendering where the color is baked-in"

[patrickhlauke]

and although there's often talk about how much better having an actual word like "Menu" is compared to hamburger icons...many devs will want it, and I do think that users are (getting) familiar with this convention.

[tomlutzenberger]

@patrickhlauke But due to the removement of the glyphicons in v4, I don't see why any kind of a menu icon is needed. If a developer wants an icon instead of the word "Menu", he/she should include some icon font like FontAwesome.

[patrickhlauke]

we also use "X" glyphs for dismissible alerts etc...so it's not the only situation where a subtle icon is in play...

[patrickhlauke]

an alternative (but slightly more involved) solution would be to switch to using SVG icons, of course...

[tomlutzenberger]

But this would mean more could to maintain.
I would stick to unicode characters (for now).

[cvrebert]

@patrickhlauke Good points. I have no objection to your improved U+2261 approach, or an SVG approach.

[acshef]

Unicode has support for forcing the text variant of an emoji, using variation selectors. http://www.unicode.org/emoji/charts/emoji-variants.html

For this case, we'd use ☰︎

Unfortunately, from what I've found only iOS supports this. (It did not fix the issue on my Samsung S5 w/ Chrome 51.0.2704.81)

[cvrebert]

Strangely, I can't seem to find U+2630 TRIGRAM FOR HEAVEN in the vanilla Noto Color Emoji font. Maybe Samsung added some glyphs without changing the font's name? Or maybe I'm not searching correctly.

[tomlutzenberger]

What? 😕
Any chances that there's some kind of a "fallback character"?

[Starsam80]

When it renders correctly on my phone, it uses the font "Noto Sans Symbols".

[Drakenhart]

A note: Gmail for their mobile mail app, uses three bullets in a vertical line to represent menus in some instances. Added point for consideration.

The Icon debate is a hot one to be sure, but icons (if they are well understood see:save icon) improves scan-ability, and fits better into a 44px square area then a word does. There are work arounds in CSS that don't even bring in the img ( or the "i" ) tag into use, so accessibility is partly covered. However, stand alone icons isn't a great idea either because not all images make the same sense and in a growing global reality.... may even be offensive to some folks from other cultures. ^.^

Wether it is a button or a link, if we use their native functions, it works for accessibility. If it's coded. Semantically. The visual is just icing on the cake.

Maybe, having a "sr-only" option for icons/images, with the associated words, allowing designers to expose that or not as they choose, may be a better way to go?

[yiays]

Why exactly did you dump the ol' reliable method of using 3 <span class="icon-bar">s anyway?
The hamburger menu icon doesn't render at all on my Vodafone 890N KitKat 4.4.4 device (this has always been the case, chrome version is irrelevant). It does still have a clickable area though. For now, I'm using the old icon-bar system to work around it as the inconsistencies that come with relying on each device's emoji font to render the symbol isn't ideal.

[patrickhlauke]

Why exactly did you dump the ol' reliable method

as v4 targets android 5.0+, it was time to move on to some more modern technologies (using <span>s, or applying border/shadow tricks, feels like a very old-school hack compared to using proper SVG or proper fonts/characters, IMO)

[yiays]

I'm not a fan of it personally; Using a font results in it rendering differently (or not at all) on a bunch of devices unless you're prepared to download a font, using some SVG magic would help, but either of these options would just add to precious loading time. Meanwhile all the code required to make the 3 <span>s trick can fit in roughly 200 bytes and can also be animated bar by bar (you can make a hamburger to x button transition, for example). If it ain't broke, don't fix it.

[tomlutzenberger]

@yesiateyoursheep So you suggest to furthermore keep a method...

1. That display's an Icon made of empty HTML? (needs to included by the Dev itself each time used while SVG can be applied by CSS class)
2. With less technical capabilities and potential? (SVG can be animated, too)
3. That supports old technology one more major version? (If Dev's want to support older Devices/Browser they should stick to v3.3.6)

If it ain't broke, don't fix it.

No offense, but IMHO in this context, it's like saying "Even if there are better and more modern ways to do it, don't change it anyway.

[yiays]

@tomlutzenberger I do like the class support and animation with SVG, but I don't like how this is default, that's a pretty harsh price to pay for a critical part of the UI not rendering on some devices.
To me, the time it takes to copy and paste the code to make a hamburger menu out of spans is well worth the backwards compatibility, I can understand wanting to use newer technologies, but I don't think it's worth it yet. Just look at the Android Version distribution;

You're aiming for support for 45.5% of Android devices. Android app developers usually have support for at least 4.0.
Using an SVG should have very high compatibility rates. I hope. But I'll be sticking with spans for another few years as is. It doesn't have enough positives to weigh out the potential negatives. Plus I just really like tinkering with CSS animations.
More than anything else, I was just arguing against using UTF symbols, it just seems like you're pushing to use new technologies for the sake of using new technologies.

Edit: Did a little research; Android 4.3 and below have partial or no support for SVGs, if devices still running >4.3 can handle running Chrome (in my case, Chrome was too slow on my old phone, so I didn't use it.) - That's 22.9% of Android users who might have invisible or even unclickable menu buttons.

[tomlutzenberger]

Partially, I agree.
But I am not sure if it is the Bootstrap teams intention to support old devices and technologies. That's what v3 is for. Version 4 should be new, modern and clean.

It's your responsibility as Developer, to make sure that your audience is capable to access the information of your website or your product they want and need. Don't shove this off to BS.
If they're using old devices back from 2000-something, don't use v4.

[Drakenhart]

Is there a way for developers/designers to change out the hamburger for something else? (like three vertically stacked dots, or wording)?

[tomlutzenberger]

You can use whatever you want.
The solution provided by Bootstrap is just a recommendation, mostly used in the examples.
What icon etc. you are using at least is your own decision.

[cvrebert]

Is there a way for developers/designers to change out the hamburger for something else?

If we go the SVG route, there will be a Sass variable you can use to swap out the inline SVG with your own SVG image.

[cvrebert]

Did a little research; Android 4.3 and below have partial or no support for SVGs,

Under the assumption that the Android Browser data on http://caniuse.com/#feat=svg also applies to Chrome when used with those Android versions, Android 3+ should support SVG (modulo masking, which shouldn't matter in our case).
And we're talking about an extremely trivial SVG here for the hamburger.

[touficbatache]

The triple bar / hamburger icon can be replaced with ≡ ['IDENTICAL TO' (U+2261) – Ed.] in the HTML code!

[cvrebert]

@touficbatache Doesn't look quite right to mdo. See #20260 (comment)
We're probably going with the SVG route: #20329

[bardiharborow]

I get this on Mac OS X 10.11.5 Chrome 53.0.2785.70 with v4.0.0-alpha.3. The issue is not present with v4.0.0-alpha.2.