Helmut Januschka (Gerrit)

unread,

Mar 9, 2026, 5:11:52 PMMar 9

to Helmut Januschka, Philip Rogers, Chromium LUCI CQ, chromium...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, zol...@webkit.org

Helmut Januschka abandoned this change.

View Change

Abandoned

Helmut Januschka abandoned this change

Related details

Attention set is empty

Submit Requirements:

Code-Coverage
Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Mar 13, 2026, 3:29:08 AMMar 13

to Helmut Januschka, Philip Rogers, Menard, Alexis, AyeAye, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Philip Rogers

Helmut Januschka added 1 comment

Patchset-level comments

File-level comment, Patchset 3 (Latest):

Helmut Januschka . resolved

this is the reland, of the revert + fixes on top from http://crrev.com/c/7646168 (that we abandoned)

we now preserve explicit author colors even if the explicit value equals the default dark focus-ring value.

The key change is that we no longer decide based on resolved color equality.

Instead, -webkit-focus-ring-color is preserved as a keyword in computed style, and PaintFocusRing() only applies the dark-mode white override when the outline color actually came from that keyword.

So explicit #101010 is preserved, but default -webkit-focus-ring-color still gets the white override in dark mode.

On platform-specific behavior: this CL intentionally keeps existing non-Mac behavior for default auto focus rings in dark mode (white for visibility). Removing that behavior, as in 7555272, causes real regressions (for example FocusRingBrowserTest.DarkModeButton and multiple dark-color-scheme blink tests), so those failures were valid.

For 7555272 specifically:

yes, it would fix crbug.com/480978106 by not overriding explicit colors,
but it also changes default focus ring behavior broadly and causes the regressions above.

The current approach is meant to fix 480978106 narrowly without those regressions.

Open in Gerrit

Related details

Attention is currently required from:

Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners

Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Mar 17, 2026, 6:43:52 AMMar 17

to Helmut Januschka, Philip Rogers, Menard, Alexis, AyeAye, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Philip Rogers

Helmut Januschka added 1 comment

Patchset-level comments

File-level comment, Patchset 3 (Latest):

Helmut Januschka . resolved

sorry, for the ping, could we proceed with this?

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Mar 25, 2026, 6:50:04 PMMar 25

to Helmut Januschka, Philip Rogers, Menard, Alexis, AyeAye, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Philip Rogers

Helmut Januschka added 1 comment

Patchset-level comments

File-level comment, Patchset 3 (Latest):

Helmut Januschka . resolved

@p...@chromium.org could you take a look at the reland? or should i try finding another reviewer?

happy to addresa any given feedback

satisfied_requirement

unsatisfied_requirement

open

diffy

Philip Rogers (Gerrit)

unread,

Mar 26, 2026, 8:24:53 PMMar 26

to Helmut Januschka, Menard, Alexis, AyeAye, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Helmut Januschka

Philip Rogers added 3 comments

Commit Message

Line 9, Patchset 3 (Latest):This relands:

Philip Rogers . unresolved

Can you include a short summary of what's actually changing in this patch from the end-user's perspective?

Line 11, Patchset 3 (Latest): (http://crrev.com/c/7633026)

Philip Rogers . unresolved

In the review of http://crrev.com/c/7633026 I asked why we need to have a platform difference at all. The answer was that we preserve the platform-specific behavior, but I don't understand why. I understand that there are platform differences in colors, but why do we have any platform differences in the overridability of colors?

Which of the fixes in this CL are platform specific?

Why is https://issues.chromium.org/u/1/issues/480978106#comment4 not the right fix?

Line 23, Patchset 3 (Latest):

Philip Rogers . unresolved

There are many pixel rebaselines in this patch, and it is difficult to determine if any of these have behavior changes (e.g., whether the new `flag-specific/enable-skia-graphite` expected files are a behavior change or are for the small pixel differences). Are these expected.png updates actually needed? If yes, do you know why the corner pixels are changing? If it's just a tiny color difference, can you adjust the `<meta name=fuzzy ` values in these tests to avoid needing to update the -expected.png files?

Open in Gerrit

Related details

Attention is currently required from:

Helmut Januschka

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review

No-Unresolved-Comments

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Mar 27, 2026, 12:52:48 PMMar 27

to Helmut Januschka, Philip Rogers, Menard, Alexis, AyeAye, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Philip Rogers

Helmut Januschka added 4 comments

Patchset-level comments

File-level comment, Patchset 5 (Latest):

Helmut Januschka . resolved

yeah bots came back with 0 pixel diffs 🥳

Commit Message

Line 9, Patchset 3:This relands:

Philip Rogers . resolved

Can you include a short summary of what's actually changing in this patch from the end-user's perspective?

Helmut Januschka

Done

Line 11, Patchset 3: (http://crrev.com/c/7633026)

Philip Rogers . resolved

In the review of http://crrev.com/c/7633026 I asked why we need to have a platform difference at all. The answer was that we preserve the platform-specific behavior, but I don't understand why. I understand that there are platform differences in colors, but why do we have any platform differences in the overridability of colors?
Which of the fixes in this CL are platform specific?
Why is https://issues.chromium.org/u/1/issues/480978106#comment4 not the right fix?

Helmut Januschka

I think the confusion came from mixing two bugs in one run.

Bug 480978106 by itself is straightforward: explicit author `outline-color` in dark mode should not be overridden.
The first attempt also tried to address 489304736 in the same change, and that is where behavior got entangled.

*Which parts are platform-specific?**
Only the pre-existing non-Mac default auto focus-ring visibility behavior in `PaintFocusRing()`.
Overridability is not platform-specific in this CL: explicit author colors are preserved on all platforms.

*Why keep any platform difference at all?**
The remaining platform difference is about default ring appearance policy (historical non-Mac white inner ring vs macOS system-style behavior), not about whether author colors can be overridden.

*Why is issue 480978106#comment4 not sufficient here?**
That approach is a good minimal fix for 480978106 alone (remove the unconditional override path).
But it does not safely cover the coupled 489304736 work, and moving white behavior into `FocusRingColor()` affects other consumers (notably canvas `drawFocusIfNeeded` / `DrawFocusRing`), which caused the regression.
Current CL keeps `FocusRingColor()` renderer-pref for canvas, and constrains white override to `PaintFocusRing()` for keyword-origin default rings.

here is a sampler: https://static.januschka.com/i-480978106/

hope that solves the doubts, really appreciate challenging it🤗!

Line 23, Patchset 3:

Philip Rogers . resolved

There are many pixel rebaselines in this patch, and it is difficult to determine if any of these have behavior changes (e.g., whether the new `flag-specific/enable-skia-graphite` expected files are a behavior change or are for the small pixel differences). Are these expected.png updates actually needed? If yes, do you know why the corner pixels are changing? If it's just a tiny color difference, can you adjust the `<meta name=fuzzy ` values in these tests to avoid needing to update the -expected.png files?

Helmut Januschka

they already have fuzzy, i think i messed up calling rebaseline script :/ - think i cleaned it up down to only a few files

Open in Gerrit

Related details

Attention is currently required from:

Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Philip Rogers (Gerrit)

unread,

Mar 27, 2026, 2:05:48 PMMar 27

to Helmut Januschka, Menard, Alexis, AyeAye, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Helmut Januschka

Philip Rogers added 1 comment

Commit Message

Line 11, Patchset 3: (http://crrev.com/c/7633026)

Philip Rogers . unresolved

In the review of http://crrev.com/c/7633026 I asked why we need to have a platform difference at all. The answer was that we preserve the platform-specific behavior, but I don't understand why. I understand that there are platform differences in colors, but why do we have any platform differences in the overridability of colors?
Which of the fixes in this CL are platform specific?
Why is https://issues.chromium.org/u/1/issues/480978106#comment4 not the right fix?

Helmut Januschka

I think the confusion came from mixing two bugs in one run.
Bug 480978106 by itself is straightforward: explicit author `outline-color` in dark mode should not be overridden.
The first attempt also tried to address 489304736 in the same change, and that is where behavior got entangled.
*Which parts are platform-specific?**
Only the pre-existing non-Mac default auto focus-ring visibility behavior in `PaintFocusRing()`.
Overridability is not platform-specific in this CL: explicit author colors are preserved on all platforms.
*Why keep any platform difference at all?**
The remaining platform difference is about default ring appearance policy (historical non-Mac white inner ring vs macOS system-style behavior), not about whether author colors can be overridden.
*Why is issue 480978106#comment4 not sufficient here?**
That approach is a good minimal fix for 480978106 alone (remove the unconditional override path).
But it does not safely cover the coupled 489304736 work, and moving white behavior into `FocusRingColor()` affects other consumers (notably canvas `drawFocusIfNeeded` / `DrawFocusRing`), which caused the regression.
Current CL keeps `FocusRingColor()` renderer-pref for canvas, and constrains white override to `PaintFocusRing()` for keyword-origin default rings.

here is a sampler: https://static.januschka.com/i-480978106/
hope that solves the doubts, really appreciate challenging it🤗!

Philip Rogers

Why must these two bugs be fixed at the same time? If just 480978106 were fixed with the simple approach, would that make it harder to fix 489304736?

Open in Gerrit

Related details

Attention is currently required from:

Helmut Januschka

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review

No-Unresolved-Comments

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Mar 31, 2026, 4:00:32 PMMar 31

to Helmut Januschka, Philip Rogers, Menard, Alexis, AyeAye, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Philip Rogers

Helmut Januschka added 1 comment

Commit Message

Line 11, Patchset 3: (http://crrev.com/c/7633026)

Philip Rogers . resolved

In the review of http://crrev.com/c/7633026 I asked why we need to have a platform difference at all. The answer was that we preserve the platform-specific behavior, but I don't understand why. I understand that there are platform differences in colors, but why do we have any platform differences in the overridability of colors?
Which of the fixes in this CL are platform specific?
Why is https://issues.chromium.org/u/1/issues/480978106#comment4 not the right fix?

Helmut Januschka

I think the confusion came from mixing two bugs in one run.
Bug 480978106 by itself is straightforward: explicit author `outline-color` in dark mode should not be overridden.
The first attempt also tried to address 489304736 in the same change, and that is where behavior got entangled.
*Which parts are platform-specific?**
Only the pre-existing non-Mac default auto focus-ring visibility behavior in `PaintFocusRing()`.
Overridability is not platform-specific in this CL: explicit author colors are preserved on all platforms.
*Why keep any platform difference at all?**
The remaining platform difference is about default ring appearance policy (historical non-Mac white inner ring vs macOS system-style behavior), not about whether author colors can be overridden.
*Why is issue 480978106#comment4 not sufficient here?**
That approach is a good minimal fix for 480978106 alone (remove the unconditional override path).
But it does not safely cover the coupled 489304736 work, and moving white behavior into `FocusRingColor()` affects other consumers (notably canvas `drawFocusIfNeeded` / `DrawFocusRing`), which caused the regression.
Current CL keeps `FocusRingColor()` renderer-pref for canvas, and constrains white override to `PaintFocusRing()` for keyword-origin default rings.

here is a sampler: https://static.januschka.com/i-480978106/
hope that solves the doubts, really appreciate challenging it🤗!

Philip Rogers

Why must these two bugs be fixed at the same time? If just 480978106 were fixed with the simple approach, would that make it harder to fix 489304736?

Helmut Januschka

They do not strictly have to be fixed together.

480978106 could land alone, but the simple version created an intermediate regression in canvas `drawFocusIfNeeded` (489304736) by changing shared `FocusRingColor()` behavior.

Landing both together avoids that broken state and keeps the split correct: explicit author colors are preserved, while default keyword focus rings keep existing visibility behavior.

Any broader 489304736 policy cleanup is better handled as a follow-up (i am happily going after this issue once this here is landed).

Open in Gerrit

Related details

Attention is currently required from:

Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

May 4, 2026, 4:14:34 PMMay 4

to Helmut Januschka, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Philip Rogers

Helmut Januschka added 1 comment

Patchset-level comments

File-level comment, Patchset 6 (Latest):

Helmut Januschka . resolved

@p...@chromium.org i dont want to stress on this, but could i ask you for a quick look if we can move on with this?

Open in Gerrit

Related details

Attention is currently required from:

Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Jun 11, 2026, 2:17:38 PMJun 11

to Helmut Januschka, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Philip Rogers

Helmut Januschka added 1 comment

Patchset-level comments

File-level comment, Patchset 7 (Latest):

Helmut Januschka . resolved

@p...@chromium.org i know you drown in reviews, yet it would be awesome if we somehow can finish this CL, if i am correct it was sorted out anyway, with the combination of both CLs mentioned in the commit history?

Open in Gerrit

Related details

Attention is currently required from:

Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Jun 22, 2026, 4:18:09 PMJun 22

to Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Fredrik Söderquist and Philip Rogers

Helmut Januschka added 1 comment

Patchset-level comments

File-level comment, Patchset 7 (Latest):

Helmut Januschka . resolved

@f...@opera.com could you maybe help unblock this? this was landed, than reverted, and now should be all-in-one, fix, flag, + a fix that came up after landing the first.

Open in Gerrit

Related details

Attention is currently required from:

Fredrik Söderquist
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Fredrik Söderquist (Gerrit)

unread,

Jun 23, 2026, 8:28:30 AMJun 23

to Helmut Januschka, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Helmut Januschka and Philip Rogers

Fredrik Söderquist added 10 comments

Patchset-level comments

File-level comment, Patchset 7:

Helmut Januschka . resolved

@f...@opera.com could you maybe help unblock this? this was landed, than reverted, and now should be all-in-one, fix, flag, + a fix that came up after landing the first.

Fredrik Söderquist

I don't feel that I have enough background on this to review it properly - there seems to have been some back-and-forth here. For example I don't understand why one platform is allowed to handle it via `LayoutTheme` and others are not. (The "<color>-on-<color>" will always be a issue if the color selection isn't dynamic - maybe the `<canvas>` `drawFocusIfNeeded()` API ought to have an optional color parameter...)

Some opinions has been bestowed though...

File third_party/blink/renderer/core/css/resolver/style_builder_converter.cc

Line 2909, Patchset 8 (Latest):

    if (value_id == CSSValueID::kWebkitFocusRingColor) {
      // Keep the keyword so PaintFocusRing() can distinguish
      // -webkit-focus-ring-color from explicit author colors that happen to
      // resolve to the same numeric value.
      return StyleColor(value_id);
    }

Fredrik Söderquist . unresolved

I think it would be better to still resolve the color as well here, to not change the computed value. Not ecstatic about increasing the level of magic ("sometimes resolve later") in play here though. I guess that technically this is a vendor extension though, so we can do what we want (but there may be issues in content).

File third_party/blink/renderer/core/paint/outline_painter_test.cc

Line 105, Patchset 8 (Latest): <div id="webkit"

Fredrik Söderquist . unresolved

`focus_ring_keyword` or something? This is not a very descriptive name.

Line 119, Patchset 8 (Latest):

  // Even if an explicit author color equals the dark default focus-ring color,
  // it should stay explicit and not be treated as -webkit-focus-ring-color.
  const auto& explicit_match_default_style =
      GetLayoutObjectByElementId("explicit_match_default")->StyleRef();
  EXPECT_TRUE(explicit_match_default_style.DarkColorScheme());
  Color explicit_match_default_color =
      explicit_match_default_style.VisitedDependentColor(
          GetCSSPropertyOutlineColor());
  EXPECT_EQ(Color(0x10, 0x10, 0x10), explicit_match_default_color);

Fredrik Söderquist . unresolved

This doesn't seem to test this though...? (The "...not be treated as -webkit-focus-ring-color" part.)

Line 154, Patchset 8 (Latest):TEST_F(OutlinePainterTest, FocusRingDarkModeColorFlagCanDisableFix) {

Fredrik Söderquist . unresolved

I don't see this disables anything? Nothing in this test seems to depend on the flag?

Line 156, Patchset 8 (Latest): RuntimeEnabledFeaturesTestHelpers::

Fredrik Söderquist . unresolved

"Don't use this class directly. Use Scoped*ForTest instead."

-> Drop this qualification

File third_party/blink/web_tests/fast/canvas/draw-focus-if-needed-dark-mode.html

Line 2, Patchset 8 (Latest):<head>

Fredrik Söderquist . unresolved

`<head>` and `<body>` can be emove.

Line 18, Patchset 8 (Latest): var ctx = document.getElementById("canvas").getContext("2d");

Fredrik Söderquist . unresolved

`const`

Line 30, Patchset 8 (Latest): var imageData = ctx.getImageData(48, 70, 1, 1);

Fredrik Söderquist . unresolved

`const`

Line 31, Patchset 8 (Latest): var data = imageData.data;

Fredrik Söderquist . unresolved

Ditto

Open in Gerrit

Related details

Attention is currently required from:

Helmut Januschka
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review

No-Unresolved-Comments

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Jul 15, 2026, 5:23:22 PM (9 days ago) Jul 15

to Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Fredrik Söderquist and Philip Rogers

Helmut Januschka added 10 comments

Patchset-level comments

File-level comment, Patchset 7:

Helmut Januschka . unresolved

@f...@opera.com could you maybe help unblock this? this was landed, than reverted, and now should be all-in-one, fix, flag, + a fix that came up after landing the first.

Fredrik Söderquist

I don't feel that I have enough background on this to review it properly - there seems to have been some back-and-forth here. For example I don't understand why one platform is allowed to handle it via `LayoutTheme` and others are not. (The "<color>-on-<color>" will always be a issue if the color selection isn't dynamic - maybe the `<canvas>` `drawFocusIfNeeded()` API ought to have an optional color parameter...)
Some opinions has been bestowed though...

Helmut Januschka

short version of the back-and-forth: first landing put the white override into LayoutTheme::FocusRingColor(), which broke canvas drawFocusIfNeeded (single-color ring drawn straight from FocusRingColor -> white on white), hence the revert.

reland keeps FocusRingColor() alone and does it in PaintFocusRing(), keyed on the outline color actually being the -webkit-focus-ring-color keyword.

on the platform split: mac's FocusRingColor() is scheme-aware (system accent, crrev.com/c/2644337).

the base one ignores color_scheme completely and just returns the renderer-pref #101010, so non-mac got the paint-time white-inner-ring hack instead (crbug.com/40135511). so not really "mac is allowed", more "only mac has a scheme-aware color source". making non-mac scheme-aware too is the follow-up in crbug.com/489304736.

moved test to external-wpt

File third_party/blink/renderer/core/css/resolver/style_builder_converter.cc

Line 2909, Patchset 8: if (value_id == CSSValueID::kWebkitFocusRingColor) {


      // Keep the keyword so PaintFocusRing() can distinguish
      // -webkit-focus-ring-color from explicit author colors that happen to
      // resolve to the same numeric value.
      return StyleColor(value_id);
    }

Fredrik Söderquist . resolved

I think it would be better to still resolve the color as well here, to not change the computed value. Not ecstatic about increasing the level of magic ("sometimes resolve later") in play here though. I guess that technically this is a vendor extension though, so we can do what we want (but there may be issues in content).

Helmut Januschka

Done. Also relaxed the DCHECK in StyleColor::GetColor() accordingly, since -webkit-focus-ring-color is now a keyword with a stored color.

File third_party/blink/renderer/core/paint/outline_painter_test.cc

Line 105, Patchset 8: <div id="webkit"

Fredrik Söderquist . resolved

`focus_ring_keyword` or something? This is not a very descriptive name.

Helmut Januschka

Done

Line 119, Patchset 8: // Even if an explicit author color equals the dark default focus-ring color,


  // it should stay explicit and not be treated as -webkit-focus-ring-color.
  const auto& explicit_match_default_style =
      GetLayoutObjectByElementId("explicit_match_default")->StyleRef();
  EXPECT_TRUE(explicit_match_default_style.DarkColorScheme());
  Color explicit_match_default_color =
      explicit_match_default_style.VisitedDependentColor(
          GetCSSPropertyOutlineColor());
  EXPECT_EQ(Color(0x10, 0x10, 0x10), explicit_match_default_color);

Fredrik Söderquist . resolved

This doesn't seem to test this though...? (The "...not be treated as -webkit-focus-ring-color" part.)

Helmut Januschka

gosh, thanks, added expect's

Line 154, Patchset 8:TEST_F(OutlinePainterTest, FocusRingDarkModeColorFlagCanDisableFix) {

Fredrik Söderquist . resolved

I don't see this disables anything? Nothing in this test seems to depend on the flag?

Helmut Januschka

Done, thx.

Line 156, Patchset 8: RuntimeEnabledFeaturesTestHelpers::

Fredrik Söderquist . resolved

"Don't use this class directly. Use Scoped*ForTest instead."
-> Drop this qualification

Helmut Januschka

Done

File third_party/blink/web_tests/fast/canvas/draw-focus-if-needed-dark-mode.html

Line 2, Patchset 8:<head>

Fredrik Söderquist . resolved

`<head>` and `<body>` can be emove.

Helmut Januschka

Done

Line 18, Patchset 8: var ctx = document.getElementById("canvas").getContext("2d");

Fredrik Söderquist . resolved

`const`

Helmut Januschka

Done

Line 30, Patchset 8: var imageData = ctx.getImageData(48, 70, 1, 1);

Fredrik Söderquist . resolved

`const`

Helmut Januschka

Done

Line 31, Patchset 8: var data = imageData.data;

Fredrik Söderquist . resolved

Ditto

Helmut Januschka

Done

Open in Gerrit

Related details

Attention is currently required from:

Fredrik Söderquist
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Fredrik Söderquist (Gerrit)

unread,

Jul 20, 2026, 8:04:20 AM (4 days ago) Jul 20

to Helmut Januschka, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Helmut Januschka, Joey Arhar and Philip Rogers

Fredrik Söderquist added 3 comments

Patchset-level comments

File-level comment, Patchset 7:

Helmut Januschka . unresolved

@f...@opera.com could you maybe help unblock this? this was landed, than reverted, and now should be all-in-one, fix, flag, + a fix that came up after landing the first.

Fredrik Söderquist

I don't feel that I have enough background on this to review it properly - there seems to have been some back-and-forth here. For example I don't understand why one platform is allowed to handle it via `LayoutTheme` and others are not. (The "<color>-on-<color>" will always be a issue if the color selection isn't dynamic - maybe the `<canvas>` `drawFocusIfNeeded()` API ought to have an optional color parameter...)
Some opinions has been bestowed though...

Helmut Januschka

short version of the back-and-forth: first landing put the white override into LayoutTheme::FocusRingColor(), which broke canvas drawFocusIfNeeded (single-color ring drawn straight from FocusRingColor -> white on white), hence the revert.
reland keeps FocusRingColor() alone and does it in PaintFocusRing(), keyed on the outline color actually being the -webkit-focus-ring-color keyword.
on the platform split: mac's FocusRingColor() is scheme-aware (system accent, crrev.com/c/2644337).
the base one ignores color_scheme completely and just returns the renderer-pref #101010, so non-mac got the paint-time white-inner-ring hack instead (crbug.com/40135511). so not really "mac is allowed", more "only mac has a scheme-aware color source". making non-mac scheme-aware too is the follow-up in crbug.com/489304736.
moved test to external-wpt

Fredrik Söderquist

None of the above is news to me. IMO a page that has a `dark` `color-scheme` but draws a "white" background (and a focus ring) on a canvas is not a UA issue. Using a specific color _always_ has the potential to backfire - "white" may only be more common in this context (not sure about that actually, transparent may be more common). Switching to "any other color" has the same problem - only potentially with lower probability. For "normal" (read: `light`) `color-scheme`, the focus ring color is "off-black" (#101010), so why wouldn't an "off-white" (#eee or so to be similar to the opposite scheme) be suitable for the `dark` case?

File-level comment, Patchset 9 (Latest):

Fredrik Söderquist . resolved

+jarhar since he's been involved in the discussion in at least one of the bugs.

File third_party/blink/web_tests/external/wpt/html/canvas/element/manual/drawing-paths-to-the-canvas/drawFocusIfNeeded_dark_color_scheme.html

Line 36, Patchset 9 (Latest):

        "The focus ring must visibly appear on the white canvas");
}, 'drawFocusIfNeeded draws a visible focus ring in a dark color-scheme.');

Fredrik Söderquist . unresolved

The spec quoted above does not say anything about this.

Open in Gerrit

Related details

Attention is currently required from:

Helmut Januschka
Joey Arhar
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Joey Arhar (Gerrit)

unread,

Jul 22, 2026, 11:31:10 AM (2 days ago) Jul 22

to Helmut Januschka, Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Helmut Januschka and Philip Rogers

Joey Arhar voted and added 2 comments

Votes added by Joey Arhar

Code-Review

+1

2 comments

File third_party/blink/renderer/core/layout/layout_theme.cc

Line 918, Patchset 13 (Latest): return Color(0xEE, 0xEE, 0xEE);

Joey Arhar . unresolved

how did you choose this color? can you add a comment explaining it?

File third_party/blink/renderer/platform/runtime_enabled_features.json5

Line 3287, Patchset 13 (Latest): name: "FocusRingRespectExplicitOutlineColorInDarkMode",

Joey Arhar . unresolved

want to add a comment saying what this does and link to a bug and say what milestone its enabled in?

Open in Gerrit

Related details

Attention is currently required from:

Helmut Januschka
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review

No-Unresolved-Comments

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

Jul 22, 2026, 5:13:17 PM (2 days ago) Jul 22

to Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Fredrik Söderquist, Joey Arhar and Philip Rogers

Helmut Januschka added 4 comments

Patchset-level comments

File-level comment, Patchset 7:

Helmut Januschka . resolved

@f...@opera.com could you maybe help unblock this? this was landed, than reverted, and now should be all-in-one, fix, flag, + a fix that came up after landing the first.

Fredrik Söderquist

I don't feel that I have enough background on this to review it properly - there seems to have been some back-and-forth here. For example I don't understand why one platform is allowed to handle it via `LayoutTheme` and others are not. (The "<color>-on-<color>" will always be a issue if the color selection isn't dynamic - maybe the `<canvas>` `drawFocusIfNeeded()` API ought to have an optional color parameter...)
Some opinions has been bestowed though...

Helmut Januschka

short version of the back-and-forth: first landing put the white override into LayoutTheme::FocusRingColor(), which broke canvas drawFocusIfNeeded (single-color ring drawn straight from FocusRingColor -> white on white), hence the revert.
reland keeps FocusRingColor() alone and does it in PaintFocusRing(), keyed on the outline color actually being the -webkit-focus-ring-color keyword.
on the platform split: mac's FocusRingColor() is scheme-aware (system accent, crrev.com/c/2644337).
the base one ignores color_scheme completely and just returns the renderer-pref #101010, so non-mac got the paint-time white-inner-ring hack instead (crbug.com/40135511). so not really "mac is allowed", more "only mac has a scheme-aware color source". making non-mac scheme-aware too is the follow-up in crbug.com/489304736.
moved test to external-wpt

Fredrik Söderquist

None of the above is news to me. IMO a page that has a `dark` `color-scheme` but draws a "white" background (and a focus ring) on a canvas is not a UA issue. Using a specific color _always_ has the potential to backfire - "white" may only be more common in this context (not sure about that actually, transparent may be more common). Switching to "any other color" has the same problem - only potentially with lower probability. For "normal" (read: `light`) `color-scheme`, the focus ring color is "off-black" (#101010), so why wouldn't an "off-white" (#eee or so to be similar to the opposite scheme) be suitable for the `dark` case?

Helmut Januschka

i got too anchored on preserving the pure-white inner ring. updated the dark-scheme default to #eee as suggested, including drawFocusIfNeeded(), and rebaselined the assets

File third_party/blink/renderer/core/layout/layout_theme.cc

Line 918, Patchset 13: return Color(0xEE, 0xEE, 0xEE);

Joey Arhar . resolved

how did you choose this color? can you add a comment explaining it?

Helmut Januschka

#eee is the off-white counterpart to the default off-black focus-ring color (#101010). it also avoids the white-on-white drawFocusIfNeeded() regression that caused the revert. and it was mentioned in https://chromium-review.googlesource.com/c/chromium/src/+/7659602/comments/71facd5d_ad826794

File third_party/blink/renderer/platform/runtime_enabled_features.json5

Line 3287, Patchset 13: name: "FocusRingRespectExplicitOutlineColorInDarkMode",

Joey Arhar . resolved

want to add a comment saying what this does and link to a bug and say what milestone its enabled in?

Helmut Januschka

Done

File third_party/blink/web_tests/external/wpt/html/canvas/element/manual/drawing-paths-to-the-canvas/drawFocusIfNeeded_dark_color_scheme.html

Line 36, Patchset 9: "The focus ring must visibly appear on the white canvas");


}, 'drawFocusIfNeeded draws a visible focus ring in a dark color-scheme.');

Fredrik Söderquist . unresolved

The spec quoted above does not say anything about this.

Helmut Januschka

moved the test to /fast/, is this something i should try to get into spec?

Open in Gerrit

Related details

Attention is currently required from:

Fredrik Söderquist
Joey Arhar
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners

Code-Review

No-Unresolved-Comments

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Fredrik Söderquist (Gerrit)

unread,

Jul 23, 2026, 10:31:23 AM (yesterday) Jul 23

to Helmut Januschka, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Helmut Januschka, Joey Arhar and Philip Rogers

Fredrik Söderquist added 3 comments

File third_party/blink/renderer/core/css/resolver/style_builder_converter.cc

File-level comment, Patchset 18 (Latest):

Fredrik Söderquist . unresolved

I guess the changes in this file (and in `style_color.*`) are not needed anymore? I'm not convinced that we should add this complexity just for tests.

File third_party/blink/renderer/core/layout/layout_theme.cc

Line 918, Patchset 18 (Latest): return Color(0xEE, 0xEE, 0xEE);

Fredrik Söderquist . unresolved

Please use `Color::FromRGB`.

File third_party/blink/web_tests/external/wpt/html/canvas/element/manual/drawing-paths-to-the-canvas/drawFocusIfNeeded_dark_color_scheme.html

Line 36, Patchset 9:

        "The focus ring must visibly appear on the white canvas");
}, 'drawFocusIfNeeded draws a visible focus ring in a dark color-scheme.');

Fredrik Söderquist . resolved

The spec quoted above does not say anything about this.

Helmut Januschka

moved the test to /fast/, is this something i should try to get into spec?

Fredrik Söderquist

I suspect it may be intentionally left up to the UAs, but you can ask if you want.

Open in Gerrit

Related details

Attention is currently required from:

Helmut Januschka
Joey Arhar
Philip Rogers

satisfied_requirement

unsatisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

5:22 AM (12 hours ago) 5:22 AM

to Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Fredrik Söderquist, Joey Arhar and Philip Rogers

Helmut Januschka added 2 comments

File third_party/blink/renderer/core/css/resolver/style_builder_converter.cc

File-level comment, Patchset 18:

Fredrik Söderquist . resolved

I guess the changes in this file (and in `style_color.*`) are not needed anymore? I'm not convinced that we should add this complexity just for tests.

Helmut Januschka

correct, removed the changes in `style_builder_converter.cc` and `style_color.cc`, along with the test-only helper and assertions.

File third_party/blink/renderer/core/layout/layout_theme.cc

Line 918, Patchset 18: return Color(0xEE, 0xEE, 0xEE);

Fredrik Söderquist . resolved

Please use `Color::FromRGB`.

Helmut Januschka

Done

Open in Gerrit

Related details

Attention is currently required from:

Fredrik Söderquist
Joey Arhar
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review

Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

Fredrik Söderquist (Gerrit)

unread,

7:19 AM (10 hours ago) 7:19 AM

to Helmut Januschka, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Helmut Januschka, Joey Arhar and Philip Rogers

Fredrik Söderquist voted Code-Review+1

Code-Review

+1

Open in Gerrit

Related details

Attention is currently required from:

Helmut Januschka
Joey Arhar
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners

Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

open

diffy

Helmut Januschka (Gerrit)

unread,

9:10 AM (9 hours ago) 9:10 AM

to Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, Chromium LUCI CQ, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Attention needed from Joey Arhar and Philip Rogers

Helmut Januschka voted Commit-Queue+2

Commit-Queue

+2

Open in Gerrit

Related details

Attention is currently required from:

Joey Arhar
Philip Rogers

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

open

diffy

Chromium LUCI CQ (Gerrit)

unread,

9:32 AM (8 hours ago) 9:32 AM

to Helmut Januschka, Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

Chromium LUCI CQ submitted the change

Change information

Commit message:

Reland "Respect explicit outline-color for focus rings in dark mode"

In dark color-scheme pages, explicit CSS outline-color on focus rings
(for example, outline: red auto) is now respected instead of being
forced to white on non-Mac.

This relands:
- "Respect explicit outline-color for focus rings in dark mode"
   (http://crrev.com/c/7633026)
- "Add a kill switch for dark-mode explicit outline-color focus rings"
   (http://crrev.com/c/7644568)

Also include the forward-fix from CL http://crrev.com/c/7646168:
- Move the dark-mode white override back into PaintFocusRing() so
  FocusRingColor() keeps returning the renderer-pref color for canvas
  DrawFocusRing.
- Add a draw-focus-if-needed dark-mode regression test.

Bug: 480978106, 489304736

Change-Id: I1c629034f03341a9f4a9e00affa93579d4d641f7

Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7659602

Reviewed-by: Fredrik Söderquist <f...@opera.com>

Commit-Queue: Helmut Januschka <hel...@januschka.com>

Cr-Commit-Position: refs/heads/main@{#1667822}

Files:

A chrome/test/data/focus_rings/focus_ring_browsertest_dark_mode_button_chromeos.png
M chrome/test/data/focus_rings/focus_ring_browsertest_dark_mode_button_linux.png
M chrome/test/data/focus_rings/focus_ring_browsertest_dark_mode_button_win.png
M third_party/blink/renderer/core/layout/layout_theme.cc
M third_party/blink/renderer/core/layout/layout_theme_test.cc
M third_party/blink/renderer/core/paint/outline_painter.cc
M third_party/blink/renderer/core/paint/outline_painter.h
M third_party/blink/renderer/core/paint/outline_painter_test.cc
M third_party/blink/renderer/platform/runtime_enabled_features.json5
A third_party/blink/web_tests/fast/canvas/draw-focus-if-needed-dark-color-scheme.html
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/button/button-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/checkbox/checkbox-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/color/color-picker-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/date/date-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/datetimelocal-picker/datetimelocal-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/details_summary/details-with-summary-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/password/password-with-reveal-button-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/search/search-appearance-basic-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/search/search-cancel-button-clicked-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-appearance-after-closing-popup-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-inpage-appearance-basic-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-multiple-appearance-basic-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-multiple-hover-focused-unselected-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/date-suggestion-picker-appearance-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/datetimelocal-suggestion-picker-appearance-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/month-suggestion-picker-appearance-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/time-suggestion-picker-appearance-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/week-suggestion-picker-appearance-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/validation-bubble-appearance-edge-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/fast/forms/validation-bubble-appearance-wrap-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/media/audio-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/media/video-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/radio/radio-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/range/range-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/select/select-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-color-scheme/text/input-focus-ring-expected.png
M third_party/blink/web_tests/platform/linux/virtual/dark-mode-default/dark-mode/colors/web-theme-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/button/button-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/checkbox/checkbox-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/color/color-picker-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/date/date-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/datetimelocal-picker/datetimelocal-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/details_summary/details-with-summary-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/password/password-with-reveal-button-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/search/search-appearance-basic-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/search/search-cancel-button-clicked-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-appearance-after-closing-popup-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-inpage-appearance-basic-expected.png
M third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-multiple-appearance-basic-expected.png
M third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/select/select-multiple-hover-focused-unselected-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/date-suggestion-picker-appearance-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/datetimelocal-suggestion-picker-appearance-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/month-suggestion-picker-appearance-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/time-suggestion-picker-appearance-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/color-scheme/suggestion-picker/week-suggestion-picker-appearance-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/validation-bubble-appearance-edge-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/fast/forms/validation-bubble-appearance-wrap-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/media/audio-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/media/video-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/radio/radio-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/range/range-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/select/select-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-color-scheme/text/input-focus-ring-expected.png
A third_party/blink/web_tests/platform/win10/virtual/dark-mode-default/dark-mode/colors/web-theme-expected.png

Change size: M

Delta: 64 files changed, 168 insertions(+), 6 deletions(-)

Branch: refs/heads/main

Submit Requirements:

Code-Review: +1 by Fredrik Söderquist

Open in Gerrit

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

open

diffy

satisfied_requirement

luci-bisection@appspot.gserviceaccount.com (Gerrit)

unread,

3:45 PM (2 hours ago) 3:45 PM

to Helmut Januschka, Chromium LUCI CQ, Fredrik Söderquist, Philip Rogers, Menard, Alexis, android-bu...@system.gserviceaccount.com, chromium...@chromium.org, feature-me...@chromium.org, blink-revie...@chromium.org, blink-rev...@chromium.org, blink-re...@chromium.org, apavlo...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, jmedle...@chromium.org, kinuko...@chromium.org, mac-r...@chromium.org, zol...@webkit.org

luci-bi...@appspot.gserviceaccount.com has created a revert of this change

Open original change

Related details

Attention set is empty

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

open

diffy

Reply all

Reply to author

Forward

Reland "Respect explicit outline-color for focus rings in dark mode" [chromium/src : main]

Helmut Januschka (Gerrit)

Helmut Januschka abandoned this change

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 1 comment

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 1 comment

Helmut Januschka (Gerrit)

Helmut Januschka added 1 comment

Philip Rogers (Gerrit)

Philip Rogers added 3 comments

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 4 comments

Related details

Philip Rogers (Gerrit)

Philip Rogers added 1 comment

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 1 comment

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 1 comment

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 1 comment

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 1 comment

Related details

Fredrik Söderquist (Gerrit)

Fredrik Söderquist added 10 comments

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 10 comments

Related details

Fredrik Söderquist (Gerrit)

Fredrik Söderquist added 3 comments

Related details

Joey Arhar (Gerrit)

Joey Arhar voted and added 2 comments

Votes added by Joey Arhar

2 comments

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 4 comments

Related details

Fredrik Söderquist (Gerrit)

Fredrik Söderquist added 3 comments

Related details

Helmut Januschka (Gerrit)

Helmut Januschka added 2 comments

Related details

Fredrik Söderquist (Gerrit)

Fredrik Söderquist voted Code-Review+1

Related details

Helmut Januschka (Gerrit)

Helmut Januschka voted Commit-Queue+2

Related details

Chromium LUCI CQ (Gerrit)

Chromium LUCI CQ submitted the change

Change information

luci-bisection@appspot.gserviceaccount.com (Gerrit)

luci-bi...@appspot.gserviceaccount.com has created a revert of this change

Related details