Affected versions

• Firefox 77.0b5
• Firefox 78.0a1

Affected platforms

• macOS 10.15, 10.14

Steps to reproduce

1. Launch Firefox
2. Access JetLag

Expected result

• Location names are properly rendered

Actual result

• Location names are cut off

Regression range

• Recent regression, 76.0.1 seems to be not affected

Additional notes

• The issue can be seen in the attachment

The whole thing is rendered with <canvas>, so it doesn't lend itself well to quick inspection.

Jonathan: Do you think this is in any way related to font measurement APIs?

I don't think it's related to the Canvas text measurement APIs we recently implemented, as the behavior doesn't change if I disable them. My guess is that it may be a result of bug 1629787; I'll try to verify this tomorrow. Leaving needinfo for now...

Well, guessed wrong; it's nothing to do with bug 1629787.

Mozregression leads me to:

INFO: Last good revision: ad3f58c996e59bc5ca0a0e6aac61c8f6a7e51096
INFO: First bad revision: 6392325ec39e5cb10edd4aaaa4afb7a9f061b0b2
INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ad3f58c996e59bc5ca0a0e6aac61c8f6a7e51096&tochange=6392325ec39e5cb10edd4aaaa4afb7a9f061b0b2

which is bug 455077 "Enable full color_management by default".

That looked quite surprising to me, but I confirmed that setting gfx.color_management.mode back to 2 on current Nightly (and restarting the browser) makes the problem go away, and resetting it to 1 brings the problem back.

Can you attach your about:support? Are you able to reproduce on other platforms? I'm having trouble reproducing this one. Looking at the images fetched over the network, there do not appear to be any obvious images containing encoded data used by the canvas that would be messed up by color management (also bug 1631615 fixed how behaviour for untagged images). Perhaps it is the CSS colors....but then I would expect to see the same issue with Chrome. I tried using a OS X color profile on my computers which normally helps with these reproductions but no dice.

Other platforms are not affected, only macs. Tried again on 78.0a1 (2020-05-19) and is still reproducible. Chrome is not affected on my sistem. I'll attach here about:support. Please let me know if I can help with anything else.

I tried Win10 and the issue did not reproduce there; it looks like Mac-only at this point.

Comparing how the page looks with gfx.color_management.mode set to 1 vs the pre-regression setting of 2, what has changed is that the text (location names) is significantly further below the time display. It looks like the glyphs have been shifted down, but the canvas within which they're painted did not move and was not extended downwards, and so the bottom of the glyphs is clipped.

It makes no sense to me that enabling more color management should affect this, but it does: simply changing the setting of gfx.color_management.mode back to 2 is sufficient to restore the previous rendering (positioning) of the text.

I'll attach about:support from my macOS machine where this reproduces. FWIW, I tried Safe Mode and it still reproduces there.

Actually I can reproduce this also on Windows 10, though not on a different laptop which also runs Windows 10...

regression range with gfx.color_management.mode set to 1

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=25aad10380b10b6efa50c2b4d97245f078d870a0&tochange=a31334a65a1c75638efae4452ecd271450df2ad0

Maybe?
https://hg.mozilla.org/mozilla-central/rev/319d79157004e37e168599bcebcfb73b69679262

Or maybe?
https://hg.mozilla.org/mozilla-central/rev/7222707904762b443015aeb58cb9eda0b5aa21dc
which is "Bug 1406510 - rewrite TextDrawTarget to push directly into display list", which sounds possibly related.

Though I don't see why this would depend on the gfx.color_management.mode setting, or why color profile stuff would affect text positioning at all really.

https://hg.mozilla.org/mozilla-central/rev/319d79157004e37e168599bcebcfb73b69679262 reverts cleanly and reverting it does seem to fix this bug.

So it does (just tried in a local build).

As for why that affects the positioning of the text: before it draws the "problem" text strings, the site seems to do a canvas.fillText() operation with the string "|MÉq" and then calls getImageData() on the canvas. I assume it's doing that in order to examine the rendered pixels and find the highest and lowest pixels touched by the glyphs, in order to estimate ascent/descent of the font and use this to guide positioning of the actual text to be drawn.

But when color management is enabled, it changes the retrieved RGBA values of the whole background of the test canvas, not just the actual glyphs. This leads the page to believe that the test string "|MÉq" has a taller ascent than it really does, and so it adjusts its positioning of the text lower to account for this.