User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36
Firefox for Android

Steps to reproduce:

var _ctx = document.createElement("canvas").getContext("2d");
var m = _ctx.measureText("");
return m.fontBoundingBoxAscent

Actual results:

No results found for fontBoundingBoxAscent

Expected results:

a ascent number of the font need to return

It looks like this property is currently disabled by the pref dom.textMetrics.fontBoundingBox.enabled. Anyways, this is not a security bug so I'm going to unhide it.

Jonathan, what's the status of shipping the extended attributes?

We could, we've got an implementation. But last I checked, the values returned by webkit/blink/gecko aren't necessarily interoperable, e.g. see https://github.com/web-platform-tests/interop/issues/159#issuecomment-1303361603.

For these to really be useful to authors, I think they need to be more carefully specified so that we can all give consistent values. (Which may get tricky because of the legacy of fonts containing multiple, conflicting versions of metrics; and different platforms/applications having various heuristics to decide which to use...)

According to https://wpt.fyi/results/html/canvas?label=master&label=stable&aligned&q=fontboundingbox, it looks like the other browsers are shipping this, and we're the odd one out. I'm inclined to think we could pref it on.

(Looking more broadly at https://wpt.fyi/results/html/canvas?label=master&label=stable&aligned&q=2d.text.measure, there's less interop for other extended TextMetrics attributes like baselines and emheights, so I'm proposing only to flip the pref for fontBoundingBox at this stage.)

Testing locally, with the pref enabled we pass the test using Ahem, but on the one using the CanvasTest font, we have a 1px discrepancy from Chrome's result. This is because we're rounding the font metrics to pixels differently. The font and styles used by the test would in theory result in fractional-pixel metrics, but Chrome rounds the ascent and descent to the nearest pixel, while we round them up. AFAIK, the spec doesn't explicitly address this (I don't see any reason we couldn't return precise fractional-pixel values, even), and in practice metrics that come from various font backends are likely to show minor discrepancies between platforms. So I think the way forward here is to make the test use an "approx_equals" assertion, to allow for variations in how the font system computes/rounds metrics.

Taking that into account, we seem to have interoperability at a basic level on this feature, and it would be useful for authors to have it available.

Depends on D181293

Backed out for causing wpt failures at idlharness.https.html

Backout: https://hg.mozilla.org/integration/autoland/rev/3ca0465e2f35660923f4d572c2ceb4254fc931a4

Failure push: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=bca7a8665982b1110fa8b678873a845aea96999f

Failure log: https://treeherder.mozilla.org/logviewer?job_id=419852617&repo=autoland&lineNumber=13532

Backed out for causing wpt failures in idlharness.worker.html

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-PASS | /html/dom/idlharness.worker.html | TextMetrics interface: attribute fontBoundingBoxAscent - expected FAIL

Maybe make this depend on bug 1102584 and block bug 1119470 so it's easier to find.

https://hg.mozilla.org/mozilla-central/rev/16840df74cb4
https://hg.mozilla.org/mozilla-central/rev/d238e609ab5c

FF116 MDN docs can be tracked in https://github.com/mdn/content/issues/27758#issuecomment-1635199574