Open Bug 1589539 Opened 2 years ago Updated 1 month ago

text selection with fillColor and backgroundColor being the same

Categories

(Web Compatibility :: Desktop, defect, P3)

defect

Tracking

(Webcompat Priority:P3, firefox88 affected, firefox89 affected)

Webcompat Priority P3
Tracking Status
firefox88 --- affected
firefox89 --- affected

People

(Reporter: mvcmaciel, Unassigned)

References

()

Details

(Keywords: webcompat:site-wait)

Attachments

(4 files)

Attached image 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

Attached image Chrome - OK.PNG
Attached file Reduced html
Status: UNCONFIRMED → NEW
Component: Untriaged → Selection
Ever confirmed: true
Product: Firefox → Core

Reproducible on Ubuntu 18.04.

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

Component: Selection → Layout

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.

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?

Flags: needinfo?(miket)

Sorry, conflicted with comment 5 :)

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

Component: Layout → Desktop
Product: Core → Web Compatibility
Version: 71 Branch → unspecified

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?

Flags: needinfo?(miket)
Priority: -- → P3

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.

See Also: → 1510573

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

I contacted them and asking them to fix it.

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)

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

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;
    }

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

Flags: needinfo?(jfkthame)
Flags: needinfo?(emilio)
Webcompat Priority: --- → P3
Summary: Selected text is all monocolor → text selection with fillColor and backgroundColor being the same

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.

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

Flags: needinfo?(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.

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

Flags: needinfo?(jfkthame)

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

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