1589539 - text selection with fillColor and backgroundColor being the same

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Marcus Vinicius]

Attachment: Mozilla - Error.PNG

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

Steps to reproduce:

1 - Access https://www.marilan.com/contato.html using Windows 10
2 - Select text throughout the page

Actual results:

The selected is all monocolor (white), making it impossible to distinguish the text

Expected results:

Using other browsers, for instance, Chrome, the selected text is still readable

Comment 1

[Marcus Vinicius]

Attachment: Chrome - OK.PNG

Comment 2

[Alice0775 White]

Attachment: Reduced html

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia)]

Reproducible on Ubuntu 18.04.

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia)]

I don't see anything suspicious related to Core::Selection. I guess the problem is related to ::selection. Hence moving to Core::Layout.

Comment 5

[Jonathan Kew [:jfkthame]]

This is just a poorly-designed site. In https://www.marilan.com/wp-content/uploads/mk_assets/theme-options-production-1570496585.css?ver=1570496589, I found this wonderful fragment:

::-webkit-selection {
 background-color:#ffffff;
 color:#fff;
}
::-moz-selection {
 background-color:#ffffff;
 color:#fff;
}
::selection {
 background-color:#ffffff;
 color:#fff;
}

So the selection is explicitly styled as white on white, and that's what we paint.

In webkit/blink browsers, it renders somewhat visibly because they paint the selection background with partial opacity, so that the background-color: #ffffff specified in the CSS is actually rendered more like #ffffff80 or something -- I haven't checked the exact opacity value they're using. If I change the CSS in the Inspector to add a trailing 80 to the background-color value there, our rendering looks similar to Safari and Chrome's; still pretty hard to read, but not completely wiped-out.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

I mean, they're setting both the selection color and background to white, so that's what we're painting...

It seems like chrome is dishonoring the author's request and painting an rgba() background instead... I'm not sure that's expected or allowed per spec? That seems a bit weird.

I think this is a website bug... Mike have you seen something like this before?

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Sorry, conflicted with comment 5 :)

Comment 8

[Jonathan Kew [:jfkthame]]

Moving this to Webcompat, as it doesn't seem like it's really a Gecko bug per comments 5 and 6.

Comment 9

[Mike Taylor [:miketaylr]]

I don't think we've seen this type of thing before. The lack of interop here kinda sucks. :/

Would be interesting to see where Chrome decides to do this in the codebase, maybe there's some pointers to other site issues that motivated this change?

Comment 10

[Jonathan Kew [:jfkthame]]

They've been using a selection background with partial opacity for as long as I can remember; I don't think it's something that was a change motivated by specific site issues. (Note that their default highlight is also like this, so I'm assuming this was simply carried over to selection-background colors from CSS.)

In Gecko we now use partial opacity on the default selection-background color (at least on macOS, as of bug 1486204), but that's a relatively recent change; we used to use the system highlight color "as is", which was opaque.

This is closely related to what was reported in bug 1510573, where the same question of whether to apply some kind of partial transparency to a CSS-specified selection background color came up.

Comment 11

[Oana Arbuzov [:oanaarbuzov]]

The issue still occurs, selected text is not visible on Firefox Nightly.
https://prnt.sc/10i78ju

Tested with:
Browser / Version: Firefox Nightly 88.0a1 (2021-03-09)
Operating System: Windows 10 Pro

Comment 12

[Karl Dubost💡 :karlcow]

I contacted them and asking them to fix it.

Comment 13

[Karl Dubost💡 :karlcow]

Attachment: rendering in gecko, blink, webkit

This is the rendering in

• Top: Firefox Nightly 89.0a1 (2021-03-25) (64-bit)
• Middle: Microsoft Edge Version 91.0.836.0 (Version officielle) Canary (64 bits)
• Bottom: Safari Technology Preview Release 122 (Safari 14.2, WebKit 16612.1.6.2)

Comment 14

[Karl Dubost💡 :karlcow]

I extended the test case and when the background-color and color are different. The normal colors are applied so it seems there is a special case going on inside Blink and WebKit.
https://codepen.io/webcompat/pen/GRroQJa

Comment 15

[Karl Dubost💡 :karlcow]

I found this
https://source.chromium.org/chromium/chromium/src/+/6c7c23e823c8d55c2f84d6a1479b5fbe92bb7f42:third_party/WebKit/Source/WebCore/rendering/InlineTextBox.cpp;l=825-832

but that must be old code, but maybe chrome inherited from this.

    // If the text color ends up being the same as the selection background, invert the selection
    // background.
    if (textColor == c)
        c = Color(0xff - c.red(), 0xff - c.green(), 0xff - c.blue());

    GraphicsContextStateSaver stateSaver(*context);
    updateGraphicsContext(context, c, c, 0, style->colorSpace());  // Don't draw text at all!
    

In Current WebKit, this is probably it.
https://github.com/WebKit/WebKit/blob/8309593bc3f4715a365652c1a7ba9688efb4bb90/Source/WebCore/rendering/MarkedTextStyle.cpp#L87-L91

    case MarkedText::Selection: {
        style.textStyles = computeTextSelectionPaintStyle(style.textStyles, renderer, lineStyle, paintInfo, style.textShadow);

        Color selectionBackgroundColor = renderer.selectionBackgroundColor();
        style.backgroundColor = selectionBackgroundColor;
        if (selectionBackgroundColor.isValid() && selectionBackgroundColor.isVisible() && style.textStyles.fillColor == selectionBackgroundColor)
            style.backgroundColor = selectionBackgroundColor.invertedColorWithAlpha(1.0);
        break;
    }

Comment 16

[Karl Dubost💡 :karlcow]

So now I wonder if the behaviors of Blink and WebKit are more reasonable. And I wonder if not respecting the will of authors could create some breakage on websites. But given that the behavior of the dominant market share browsers do not seem to surface any webcompat issues for them, maybe the behavior should be changed and the spec should say something about it.

1. Change the spec that when fillColor == backgroundColor for text selection, we should use algorithm… blah
2. Create webplatform test for it
3. Implement it in Gecko

Opinion? Jonathan, Emilio

Comment 17

[Karl Dubost💡 :karlcow]

The current spec says:
https://drafts.csswg.org/css-pseudo-4/#highlight-replaced

For non-replaced content, the UA must honor the color and background-color (including their alpha channels) as specified.

which is what Gecko does currently.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

I tracked down that WebKit line of code to this changeset, which is way before the ::selection pseudo-element existed, I think.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Not opposed to push for the spec change but if it's only one website, I think we could try to convince other browsers to follow the spec.

Comment 20

[Jonathan Kew [:jfkthame]]

(In reply to Karl Dubost💡 :karlcow from comment #16)

So now I wonder if the behaviors of Blink and WebKit are more reasonable. And I wonder if not respecting the will of authors could create some breakage on websites. But given that the behavior of the dominant market share browsers do not seem to surface any webcompat issues for them, maybe the behavior should be changed and the spec should say something about it.

1. Change the spec that when fillColor == backgroundColor for text selection, we should use algorithm… blah
2. Create webplatform test for it
3. Implement it in Gecko

Opinion? Jonathan, Emilio

Tend to agree with Emilio, the first thing to do here (given that AFAIK we haven't been getting reports of this all over the place, it's this particular site that has CSS that just doesn't make sense unless they really WANTED the selection to be invisible) is to push for people to follow the spec. It's clear enough on this point, and it shouldn't be hard for authors to use it.

Defining special behavior for fillColor == backgroundColor for text selection gets messy; what about if the colors aren't exactly equal but differ by so little that it's not visible to the eye? We'd probably want to do this in terms of computing the contrast between them, not simple equality, and enforcing a minimum level of contrast. But then we'll end up with some author complaining that a subtle effect they're trying to achieve is impossible because the browser refuses to apply their colors as specified.

Comment 21

[Karl Dubost💡 :karlcow]

Current status of the discussion on the CSS WG:
Needs to be discussed more and explore all the cases when there is such an issue.
People are for now being positive on having something drafted to avoid the interop issues.
Details at: https://github.com/w3c/csswg-drafts/issues/6150#issuecomment-816262313

Comment 22

[Raul Bucata]

I was able to reproduce the issue. The highlighted text is not visible:

https://prnt.sc/qnufF-23oUMS

Tested with:

Browser / Version: Firefox Release 100.0 (64-bit)/ Firefox Nightly 102.0a1 (2022-05-03) (64-bit) / Chrome Version Version 101.0.4951.54 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome

Comment 23

[Raul Bucata]

The issue is still reproducible

Tested with:

Browser / Version: Firefox Nightly 111.0a1 (2023-01-16) (64-bit)
Operating System: Windows 10 PRO x64