Bug 258725 – Stop resolving border's current color to some hardcoded value

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Vitaly Dyackhov]

In `Color RenderStyle::colorResolvingCurrentColor(CSSPropertyID colorProperty, bool visitedLink) const` we currently return some hardcoded value for border colors:
```
auto result = unresolvedColorForProperty(colorProperty, visitedLink);

if (result.isCurrentColor()) {
    auto borderStyle = [&] {
        switch (colorProperty) {
        case CSSPropertyBorderLeftColor:
            return borderLeftStyle();
        case CSSPropertyBorderRightColor:
            return borderRightStyle();
        case CSSPropertyBorderTopColor:
            return borderTopStyle();
        case CSSPropertyBorderBottomColor:
            return borderBottomStyle();
        default:
            return BorderStyle::None;
        }
    }();

    if (!visitedLink && (borderStyle == BorderStyle::Inset || borderStyle == BorderStyle::Outset || borderStyle == BorderStyle::Ridge || borderStyle == BorderStyle::Groove))
        return { SRGBA<uint8_t> { 238, 238, 238 } };

    return visitedLink ? visitedLinkColor() : color();
}

```

I can't think of any good reason for doing this.

The result can be unexpected for web developers.

[Vitaly Dyackhov]

Pull request: https://github.com/WebKit/WebKit/pull/15447

[Radar WebKit Bug Importer]

<rdar://problem/111905474>

[Ahmad Saleem]

*** Bug 256528 has been marked as a duplicate of this bug. ***

[EWS]

Committed 266134@main (0aa032e26bbd): <https://commits.webkit.org/266134@main>

Reviewed commits have been landed. Closing PR #15447 and removing active labels.

[Simon Fraser (smfr)]

Do we understand why this code was added in the first place?

[Simon Fraser (smfr)]

This caused https://bugs.webkit.org/show_bug.cgi?id=261847

[Tim Nguyen (:ntim)]

*** Bug 195015 has been marked as a duplicate of this bug. ***