1573676 - text-decoration-skip-ink seems overzealous with "Ubuntu" font

Status: VERIFIED DUPLICATE of bug 1573218

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STR:

1. Load attached testcase (with pref layout.css.text-decoration-skip-ink.enabled = true).
2. Inspect the underline ink-skipping.

ACTUAL RESULTS:
The ink-skipping seems overzealous. In particular:

• "a" isn't fully underlined.
• "e" and "c" have an extremely skinny underline
• The start of the "b" underline seems awkward/offset.
  (In all three cases, there is some nearby ink to skip, but we seem to be skipping too much)

EXPECTED RESULTS:

• "a", "e", and "c" should have wider underlines, as wide (or nearly as wide) as the characters.
• The start of the "b" underline should not be offset.

Chrome gives EXPECTED RESULTS. Firefox Nightly (with the pref enabled) gives ACTUAL RESULTS.

Note: the testcase includes a data URI encoding of the "Ubuntu Bold" font which is included by default in Ubuntu, and specifically used in Confluence and probably other platforms. In Mozilla's confluence installation, the font is referenced here: https://mana.mozilla.org/wiki/s/1bb27c65f9d127c7b8ae49a61cdc30e4-CDN/en_US/7901/0b59262db6a7cd3dbeee6d1b1416b77c01706b36/ec85741cad785658e5d334cee8aab0ba/_/download/contextbatch/css/_super/batch.css

body {
  color: #172b4d;
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen",
               "Ubuntu", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;
  font-size: 14px;
  font-weight: 400;
  line-height: 1.42857143;
  letter-spacing: 0
}

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot (Firefox on top, Chrome on bottom)

Comment 2

[Daniel Holbert [:dholbert]]

Charlie, do you know what's going on here?

(Is there a known/intentional behavior-difference where we add more padding than Chrome does, when ink-skipping?)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of Safari

Here's a screenshot of Safari 12.1 (viewed remotely via BrowserStack). Their ink-skipping seems like an even-closer shave than Chrome's. (For example, Safari's underline projects a bit to the left side of the "e" and the "b" characters in the testcase, as compared to Chrome where it stops around the left edge of those characters [and Firefox Nightly where it doesn't even reach the left edge of those characters right now].)

So, our implementation seems to be significantly more cautious (i.e. it has wider skips) than both other implementations of this feature, at least in this testcase.

Comment 4

[Charlie Marlow [:cmarlow]]

Attachment: Screen Shot 2019-08-13 at 2.41.41 PM.png

Looks like this will be resolved by https://bugzilla.mozilla.org/show_bug.cgi?id=1573218, which lands either later today or tomorrow. I've attached a screenshot of the test case with this patch applied.

Comment 5

[Daniel Holbert [:dholbert]]

Thanks! Yeah, that screenshot looks more like what I'd expect here.

Duping for now; we can un-dupe if it doesn't end up fixing things for some reason.

Comment 6

[Jonathan Kew [:jfkthame]]

Right, this is bug 1573218, and the about-to-land patch will fix it.

(Our result still won't exactly match either Chrome or Safari because they don't respect the font's underlineThickness value, but make up their own.)

Comment 7

[Daniel Holbert [:dholbert]]

This indeed looks much better in today's nightly (by virtue of bug 1573218's patch).

--> VERIFIED dupe