Closed Bug 1573676 Opened 3 years ago Closed 3 years ago

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


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






(Reporter: dholbert, Unassigned)



(4 files)

Attached file testcase 1


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

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)


  • "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:

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

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

Flags: needinfo?(charles.w.marlow)
Attached image 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.

Looks like this will be resolved by, which lands either later today or tomorrow. I've attached a screenshot of the test case with this patch applied.

Flags: needinfo?(charles.w.marlow)

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.

Closed: 3 years ago
Resolution: --- → DUPLICATE
No longer blocks: 1573631

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

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

--> VERIFIED dupe

You need to log in before you can comment on or make changes to this bug.