www.google.com - Drop-down menu arrows are misaligned on “Nutrition” knowledge panel

[softvision-oana-arbuzov]

URL: https://www.google.com/search?biw=1024&bih=720&ei=Qb-JWe3RNMXwUMDboqgH&q=Grapes+nutrition&oq=Grapes+nutrition&gs_l=mobile-gws-serp.3..0i67k1j0i20k1j0i7i10i30k1j0l2.3605.6661.0.7677.12.12.0.0.0.0.415.3728.2-4j5j2.11.0....0...1..64.mobile-gws-serp..8.4.1487...0i7i30k1.mAEFkoys2RE

Browser / Version: Firefox Mobile Nightly 57.0a1 (2017-08-07) - Chrome UA
Operating System: Nexus 9 (Android 7.1.1) - Resolution 1536 x 2048 pixels (~281 ppi pixel density)
Tested Another Browser: Yes

Problem type: Design is broken
Description: Drop-down menu arrows are misaligned on “Nutrition” knowledge panel
Steps to Reproduce:

1. Navigate to: https://www.google.com/search?biw=1024&bih=720&ei=Qb-JWe3RNMXwUMDboqgH&q=Grapes+nutrition&oq=Grapes+nutrition&gs_l=mobile-gws-serp.3..0i67k1j0i20k1j0i7i10i30k1j0l2.3605.6661.0.7677.12.12.0.0.0.0.415.3728.2-4j5j2.11.0....0...1..64.mobile-gws-serp..8.4.1487...0i7i30k1.mAEFkoys2RE.
2. Scroll down to the “Nutrition” knowledge panel.
3. Observe “Nutrition Facts/Amount Per” drop-down menu arrows alignment.

Expected Behavior:
Arrows are centered.

Actual Behavior:
Arrows are misaligned (top side).

Note:

1. Reproducible on on Firefox 54.0.1 Release and Firefox Nightly 57.0a1 (2017-08-02) without Chrome UA.
2. Reproducible on phone and tablet layout.
3. Not reproducible on Chrome (Mobile) 59.0.3071.125.
4. Screenshot attached.

Watchers:
@softvision-sergiulogigan
@softvision-oana-arbuzov

sv; gs

From webcompat.com with ❤️

[karlcow]

Not sure this is significant enough to really dig further.

[wisniewskit]

This is site error similar in spirit to what's happening in #8635. They're basically relying on the browser engine to lay things out exactly like Chrome would when engines have too much leeway to not do so. They really should just be using flexbox so the engine lays things out according to their intent instead. For instance, it does the trick to add this rule:

._Fih {
  display: flex;
  align-items: center;
  justify-content: center;
}

And drop these:

._hih {
  bottom: 1px;
  pointer-events: none;
  position: absolute;
  right: 1px;
}

[miketaylr]

@wisniewskit is this a dupe of #8642?

[wisniewskit]

It's similar in spirit, but they're relying on different CSS here than in #8642, and I can't tell if they rely on the same Blink code for layout.

[foolip]

Shortened URL for ease of testing is https://goo.gl/PoywA2.

I can reproduce a small difference. In addition to the arrow being slightly further up on Firefox, its diagonals are a lot more jagged, which looks worse to me than the misalignment.

[foolip]

Does anyone already know which CSS spec governs this, and if the leeway mentioned is intentional?

[wisniewskit]

@foolip, I'm guessing it should be CSS Fonts? I don't know for sure because I see no spec trying to carefully define this behavior (though I'm not such an expert that I would know for sure).

Note that for the current page design, Firefox is choosing the Clear Sans font rather than Roboto, because of issue #7292 (the page is using the Postscript font name "Roboto-Regular" which Blink erroneously supports, instead of just using "Roboto").

But even when I adjust the CSS to only use "Roboto", the two don't render similarly. Firefox is placing the text's baseline lower in its containing box, so the data-URL "arrow" bitmap looks to be offset a bit higher than it does in Chrome.

This seems likely to be related to what I'm seeing in Firefox bug 1406552... perhaps @jfkthame can chime in here and shed some more light on the spec situation (and maybe on what could be done aside from using flexbox instead of relying on baselines being the same across browsers for alignment).

As for why the bitmap arrow icon appears to be more jagged in Firefox, I'm not sure. However using a simple SVG data-URL instead of a bitmap fixes this (and strikes me as a safer solution). Something like this would do the trick, and I recall it working on modern browsers and Explorer 10/11:

._hih {
  background:url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 50'><polygon points='0,0 100,0 50,50'/%3E%3C/svg%3E") no-repeat center center;
}

Edit: the PNG is a 7x4 pixel image; maybe Firefox isn't antialiasing it because of its small size, and then it looks bad when upscaled. I'll have to investigate that further.

[wisniewskit]

Here is a reduced version of the in-page markup, with outlines of the related elements colored differently:

<!DOCTYPE html>
<html>
<body>
<head>
<style>
div, span {
    font-family: Roboto,HelveticaNeue,Arial,sans-serif;
    font-weight: 400;
    font-size: 14px;
    line-height: 20px;
}
._she {
    outline: 1px solid yellow;
    background-color: #fbfbfb;
    display: inline-block;
    height: 1.3em;
    max-width: 100%;
    overflow: hidden;
    position: relative;
}
._Fih {
    outline: 1px solid red;
    overflow: hidden;
    padding-right: 19px;
}
.kno-nf-sbl {
    outline: 1px solid blue;
}
._hih {
    outline: 1px solid green;
    background: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAcAAAAECAYAAABCxiV9AAAAHklEQVR4AWOIjIz8jwuDJHEpYIBJMqBLwCTRFCD4AFLRLSVEKqcrAAAAAElFTkSuQmCC) no-repeat center center;
    bottom: 1px;
    height: 1.2em;
    position: absolute;
    right: 1px;
    width: 11px;
}
</style>
</head>
<body>
<div class="_ULb _she">
<div class="_Fih">
<span class="kno-nf-sbl">100 grams</span>
<div class="_hih"></div>
</div>
</div>
</body>
</html>

[foolip]

I've minimized this a bit further:

<!DOCTYPE html>
<meta name="viewport" content="width=device-width">
<style>
.a {
  position: absolute;
  height: 21px;
  outline: 1px solid orange;
  padding-right: 19px;
}

.b {
  background: orange url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAcAAAAECAYAAABCxiV9AAAAHklEQVR4AWOIjIz8jwuDJHEpYIBJMqBLwCTRFCD4AFLRLSVEKqcrAAAAAElFTkSuQmCC) no-repeat center center;
  bottom: 1px;
  height: 19px;
  position: absolute;
  right: 1px;
  width: 11px
}
</style>
<div class="a">
 Grapes
 <div class="b"></div>
</div>

I can't quite tell why there's a difference between Chrome and Firefox still. The next is a tad further down in Chrome, and I think that could account for the whole difference, but I don't understand why there's more whitespace below the class="b" div in Firefox.

@miketaylr @wisniewskit help?

[karlcow]

• font-family: Clear Sans on Firefox Android
• font-family: Roboto on Chrome Android

if I force both with font-family: Roboto

https://bugzilla.mozilla.org/show_bug.cgi?id=1392147

[foolip]

Thanks @karlcow!

[flackr]

As far as I can tell the postscript name matching is only an issue on Chrome for Mac and the only reason we get Roboto on Android is because it is the sans-serif font and aliased from Arial.

See https://bugs.chromium.org/p/chromium/issues/detail?id=641861#c24 for details on the Chrome bug. TLDR; we will fix this bug on Chrome for mac but the bug is not causing Chrome for android to select Roboto.

[karlcow]

@flackr

the only reason we get Roboto on Android is because it is the sans-serif font and aliased from Arial.

Ah interesting! Are there other aliases? for serif, sans-serif, etc. A link to the source code of Chrome Android is fine.

Thanks.

[flackr]

There sure are, see the mappings here:
https://cs.chromium.org/chromium/src/third_party/android_tools/sdk/platforms/android-27/data/fonts/fonts.xml?dr=C&ssfr=1

[softvision-sergiulogigan]

The issue is still reproducible on my side, using a Chrome UA.

Tested with:
Browser / Version: Firefox Nightly 68.1a1 (2019-08-13)
Operating System: Sony Xperia Z2 (Android 6.0.1) - 1080 x 1920 pixels, 16:9 ratio (~424 ppi pixel density)

[cipriansv]

I retested the issue and it is still reproducible.

Tested with:
Browser / Version: Browser / Version: Firefox 68.9.0 - UA set to Chrome
Operating System: Huawei P10 (Android 9.0) - 1080 x 1920 pixels (~432 ppi pixel density)