On some websites, the readability backplate implemented at bug 1539212 seems to spill out the left side of the text.

The best example I've found of this is at apple.com where I see it on most pages. I think the same issue is also happening at amazon.com and theverge.com which I document here in screenshots.

Tested on Windows 10 with High Contrast Black OS theme active in today's Nightly build.

Hmm yeah I think this is because we include margin space in visual overflow.

Looks like this is an issue with centered text?

Frame dump for above test case; looks like the visual overflow for both text objects is the same, but the visual overflow for the lines differs... hmm. @dholbert: any ideas re: getting the text's overflow instead of the line's overflow? I'm a bit confused how to navigate this situation given the simultaneous requirement that backplates be drawn for chunks of lines...

          Block(body)(2)@112b26b38 parent=112b26a78 {480,480,99840,2304} [state=0200020000100200] [content=1129e11f0] [cs=10a1983e8]<
            line 112b26fa8: count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,before:nobr,after:nobr[0x108] {6000,0,93840,1152} vis-overflow=5970,0,93870,1152 scr-overflow=6000,0,93840,1152 <
              Block(div)(1)@112b26c48 parent=112b26b38 next=112b26df8 {6000,0,93840,1152} vis-overflow={-30,0,93870,1152} scr-overflow={0,0,93840,1152} [state=0200020000100210] [content=112bb35e0] [cs=10a199798]<
                line 112b26da8: count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,before:nobr,after:nobr[0x100] {0,0,1334,1152} vis-overflow=-30,0,1634,1152 scr-overflow=0,0,1334,1152 <
                  Text(0)"\n    test\n  "@112b26d08 parent=112b26c48 {0,96,1334,960} vis-overflow={-30,0,1634,960} scr-overflow={0,0,1334,960} [state=02000040b0600000] [content=112b78c80] [cs=10a199a68:-moz-text] [run=112bb3ca0][0,12,T] 
                >
              >
            >
            line 112b26ff8: count=1 state=block,clean,prevmarginclean,not-impacted,not-wrapped,before:nobr,after:nobr[0x8] {0,1152,99840,1152} <
              Block(div)(3)@112b26df8 parent=112b26b38 {0,1152,99840,1152} [state=0200020000100210] [content=112bb3670] [cs=10a199888]<
                line 112b26f58: count=1 state=inline,clean,prevmarginclean,not-impacted,not-wrapped,before:nobr,after:nobr[0x100] {49253,0,1334,1152} vis-overflow=0,0,50857,1152 scr-overflow=0,0,50587,1152 <
                  Text(0)"\n    test\n  "@112b26eb8 parent=112b26df8 {49253,96,1334,960} vis-overflow={-30,0,1634,960} scr-overflow={0,0,1334,960} [state=02000040b0600000] [content=112b78d80] [cs=10a199b58:-moz-text] [run=112bb3dc0][0,12,T] 
                >
              >

(In reply to Morgan Reschenberg [:morgan] from comment #10)

Frame dump for above test case; looks like the visual overflow for both text objects is the same, but the visual overflow for the lines differs... hmm. @dholbert: any ideas re: getting the text's overflow instead of the line's overflow? I'm a bit confused how to navigate this situation given the simultaneous requirement that backplates be drawn for chunks of lines...

Hmm.... We should perhaps investigate why the line's visual overflow area is so large -- I suspect it doesn't need to be that big.

I've got a testcase with some more examples. Also, tangent: linear-gradient(...) counts as a "background image" and it's a nice handy way to build testcases without needing to use a real image every time.

Edge renders testcase 2 with "tightly-wrapped" backplates for every run of text, for what it's worth.

Also: I suspect bug 1593267 is a version of this same underlying bug (at least, the extra backplating on the left side of each button there looks likely to be this same issue). --> marking that bug as depending on this one.

(For the record: this affects our privacy notice page, too -- https://www.mozilla.org/en-US/privacy/firefox/ .

That page has a mozilla logo (moz://a) at the top left, as a background-image, with some invisible text that's positioned off of the right side (and intentionally clipped) via text-indent: 120%; overflow: hidden. The intentionally-clipped text here seems to be serving the role of "alt text", basically.

Right now, this intended-to-be-hidden text is leaving a backplate in its text-indent "wake", and that backplate stomps on top of the mozilla logo image.

I fixed a typo in testcase 2, and added two additional interesting cases:

• nested spans, where the inner one has a margin. (We start the backplate at the start of the outer span -- technically at the beginning of the line -- while edge still starts the backplate at the text.

• a span with padding, and another one with border. (These both contribute to the span's visible-overflow-area, because the whole border-box gets drawn with the frame's CSS background [if it has a CSS background], so that whole area will need repainting if the frame is restyled/transformed. However: the border & padding doesn't meaningfully contribute to area that we'd want to backplate, really, because there's no text there.

These ^ scenarios are leading me to think that we shouldn't be using visible-overflow after all (not even the visible overflow of the direct children), and instead, we want to be looking for text frames specifically, and only creating (and unioning) backplate area for them....

AIUI the backplate is disabled in beta.

https://hg.mozilla.org/integration/autoland/rev/c25dd569f2cf117520a20595caac4c0ac17e5b8a

Backed out changeset c25dd569f2cf (bug 1594099) for Reftest failures on reftests/high-contrast/backplate-bg-image-012.html. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=280716218&repo=autoland&lineNumber=26406

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=c25dd569f2cf117520a20595caac4c0ac17e5b8a

Backout:
https://hg.mozilla.org/integration/autoland/rev/34dabacbfd36d3e7d223813ee4d407b66028e633

https://hg.mozilla.org/mozilla-central/rev/e3362078c7bb