Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
288983010:
fix text color of BlueButton on GTK-theme-mode Linux Aura. (Closed)
|
Created:
6 years, 7 months ago by Evan Stade Modified:
6 years, 6 months ago CC:
chromium-reviews, tfarina Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
Descriptionfix text color of BlueButton on GTK-theme-mode Linux Aura.
BUG=375350
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=275225
Patch Set 1 #
Total comments: 2
Patch Set 2 : set bg color based on state #
Total comments: 4
Patch Set 3 : themify colors instead #
Total comments: 12
Patch Set 4 : CallToAction->Blue #Patch Set 5 : add colors to common theme #
Messages
Total messages: 33 (0 generated)
https://codereview.chromium.org/288983010/diff/1/ui/views/controls/button/lab... File ui/views/controls/button/label_button.cc (right): https://codereview.chromium.org/288983010/diff/1/ui/views/controls/button/lab... ui/views/controls/button/label_button.cc:373: label_->SetAutoColorReadabilityEnabled(border() != default_border); Do we want to be executing all this outside of BlueButton?
+msw for special insights into what I might be breaking https://codereview.chromium.org/288983010/diff/1/ui/views/controls/button/lab... File ui/views/controls/button/label_button.cc (right): https://codereview.chromium.org/288983010/diff/1/ui/views/controls/button/lab... ui/views/controls/button/label_button.cc:373: label_->SetAutoColorReadabilityEnabled(border() != default_border); On 2014/05/23 21:07:01, Elliot Glaysher wrote: > Do we want to be executing all this outside of BlueButton? I guess I get why you're asking -- because normal LabelButton doesn't need it. But any time there's a non-default text color set, it is useful (BlueButton is only one such instance). I don't think it should hurt to have this even for normal LabelButtons. If there's a GTK theme where the fg and bg colors aren't distinguishable from each other, that's broken. But your question did make me investigate more and I found that hovering a bluebutton with highcontrastinverse applied would leave the text white on a white background. That's fixed by changing the background color of the label in StateChanged().
ping msw
https://codereview.chromium.org/288983010/diff/20001/ui/views/controls/button... File ui/views/controls/button/label_button.cc (right): https://codereview.chromium.org/288983010/diff/20001/ui/views/controls/button... ui/views/controls/button/label_button.cc:383: label_->SetBackgroundColor(GetNativeTheme()->GetSystemColor( Does this work right if gfx::IsInvertedColorScheme() adds a visible solid black background to the button? (maybe that doesn't happen at all on Linux?)
https://codereview.chromium.org/288983010/diff/20001/ui/views/controls/button... File ui/views/controls/button/label_button.cc (right): https://codereview.chromium.org/288983010/diff/20001/ui/views/controls/button... ui/views/controls/button/label_button.cc:383: label_->SetBackgroundColor(GetNativeTheme()->GetSystemColor( On 2014/05/29 02:03:55, msw wrote: > Does this work right if gfx::IsInvertedColorScheme() adds a visible solid black > background to the button? (maybe that doesn't happen at all on Linux?) Do I need a Windows machine to test that? Is the bg black even when hovered for inverted color schemes? Why are the inverted colors not piped through the nativetheme? I guess I can guard this with !gfx::IsInvertedColorScheme().
https://codereview.chromium.org/288983010/diff/20001/ui/views/controls/button... File ui/views/controls/button/label_button.cc (right): https://codereview.chromium.org/288983010/diff/20001/ui/views/controls/button... ui/views/controls/button/label_button.cc:371: label_->SetAutoColorReadabilityEnabled(border() != default_border); Should the label background color be initialized here? It only happens on StateChanged for Linux Desktop, and otherwise this readability behavior might use some default/uninitialized value. In testing, this seems to only apply "readable" colors to the normal state after a hover. https://codereview.chromium.org/288983010/diff/20001/ui/views/controls/button... ui/views/controls/button/label_button.cc:383: label_->SetBackgroundColor(GetNativeTheme()->GetSystemColor( On 2014/05/29 19:04:45, Evan Stade wrote: > On 2014/05/29 02:03:55, msw wrote: > > Does this work right if gfx::IsInvertedColorScheme() adds a visible solid > black > > background to the button? (maybe that doesn't happen at all on Linux?) > > Do I need a Windows machine to test that? Yeah, IsInvertedColorScheme is only supported on Windows for now, but I tested this for you. > Is the bg black even when hovered for inverted color schemes? Yes, we draw a black rectangle under the label (but not covering the whole button), regardless of the button state, so that the text is readable to those with visibility needs. > Why are the inverted colors not piped through the nativetheme? The inverted color scheme support and design is abysmal and needs an overhaul, along with the pattern of painting image assets here, rather than through NativeTheme. We already need a LabelButton 2.0 :( > I guess I can guard this with !gfx::IsInvertedColorScheme(). Yes, your CL as-is breaks the normal state text color for the Windows High Contrast Black system theme (but only after the initial hover; see my other CL comment above). Simply adding a !gfx::IsInvertedColorScheme() condition here would be appropriate for now (it prevents the breakage this would otherwise introduce).
I changed this patch significantly in order to make it less disruptive and also to pave the way for future improvements. Specifically, after some more work, BlueButtons should look different to normal buttons on GTK NativeThemes.
+ben for OWNERS
This approach looks much better. LGTM.
ping ben, msw
https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:239: // TODO(estade): determine a more distinct color for the CallToAction How about using the existing button colors above (with the same values here), and doing SetAutoColorReadabilityEnabled on the label to handle cases where the system colors don't work? Perhaps that will typically yield white as expected/spec'ed, and it seems like we ought to use readable versions of the system colors anyway. https://codereview.chromium.org/288983010/diff/40001/ui/native_theme/fallback... File ui/native_theme/fallback_theme.cc (right): https://codereview.chromium.org/288983010/diff/40001/ui/native_theme/fallback... ui/native_theme/fallback_theme.cc:41: static const SkColor kCallToActionButtonEnabledColor = SK_ColorWHITE; nit: one const or inlined values would suffice for now. https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... File ui/views/controls/button/blue_button.cc (right): https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... ui/views/controls/button/blue_button.cc:49: // TODO(estade): this is not great on system themes. Perhaps we could use a partially transparent version of the text color? That's probably how the original shadow color was calculated (expecting white on blue).
https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:239: // TODO(estade): determine a more distinct color for the CallToAction On 2014/06/02 21:06:20, msw wrote: > How about using the existing button colors above (with the same values here), > and doing SetAutoColorReadabilityEnabled on the label to handle cases where the > system colors don't work? Perhaps that will typically yield white as > expected/spec'ed, and it seems like we ought to use readable versions of the > system colors anyway. I don't follow. This code just makes blue buttons look like normal buttons. There's no other option right now, except to make blue buttons never be themed, which looks way worse IMO. https://codereview.chromium.org/288983010/diff/40001/ui/native_theme/fallback... File ui/native_theme/fallback_theme.cc (right): https://codereview.chromium.org/288983010/diff/40001/ui/native_theme/fallback... ui/native_theme/fallback_theme.cc:41: static const SkColor kCallToActionButtonEnabledColor = SK_ColorWHITE; On 2014/06/02 21:06:20, msw wrote: > nit: one const or inlined values would suffice for now. this follows the precedent set by the rest of this function https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... File ui/views/controls/button/blue_button.cc (right): https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... ui/views/controls/button/blue_button.cc:49: // TODO(estade): this is not great on system themes. On 2014/06/02 21:06:20, msw wrote: > Perhaps we could use a partially transparent version of the text color? That's > probably how the original shadow color was calculated (expecting white on blue). I'd be inclined to have no shadow on gtk system themes (fully transparent), while leaving this color as the default in fallback theme. But exploring all the options is a TODO.
Can you post some screenshots on the bug? Are BlueButtons not blue in the GTK-theme-mode? If so, why isn't that the defect that you're aiming to fix for Issue 375350? Otherwise, if we never want BlueButtons to be blue buttons in GTK-theme-mode, then we should probably just use LabelButton directly instead of hacking up BlueButton to work correctly as a beige/white gtk-styled button. https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:239: // TODO(estade): determine a more distinct color for the CallToAction On 2014/06/02 22:18:14, Evan Stade wrote: > On 2014/06/02 21:06:20, msw wrote: > > How about using the existing button colors above (with the same values here), > > and doing SetAutoColorReadabilityEnabled on the label to handle cases where > the > > system colors don't work? Perhaps that will typically yield white as > > expected/spec'ed, and it seems like we ought to use readable versions of the > > system colors anyway. > > I don't follow. This code just makes blue buttons look like normal buttons. > There's no other option right now, except to make blue buttons never be themed, > which looks way worse IMO. Yeah, I suggest (1) using readable versions of these normal button text colors. We need readable colors because users with blue text colors won't be able to read blue text on blue buttons. I'm also suggesting (2) possibly removing these new color ids. I'm hoping that we can just use the normal color ids (like kColorId_ButtonEnabledColor above) everywhere and still get something legible and close to spec.
On 2014/06/02 22:39:44, msw wrote: > Can you post some screenshots on the bug? I could but they would not be interesting. They would just be normal buttons in place of BlueButtons. > > Are BlueButtons not blue in the GTK-theme-mode? No. > If so, why isn't that the defect > that you're aiming to fix for Issue 375350? Because the more pressing defect is the illegible text. > Otherwise, if we never want > BlueButtons to be blue buttons in GTK-theme-mode, then we should probably just > use LabelButton directly instead of hacking up BlueButton to work correctly as a > beige/white gtk-styled button. a) we do want BlueButtons to have a special color, and this patch provisions for that future without actually implementing it (yet) b) I don't know of a clean way to swap out the entire class based on the native theme, especially given that the native theme can change. > > https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... > File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): > > https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... > chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:239: // TODO(estade): determine > a more distinct color for the CallToAction > On 2014/06/02 22:18:14, Evan Stade wrote: > > On 2014/06/02 21:06:20, msw wrote: > > > How about using the existing button colors above (with the same values > here), > > > and doing SetAutoColorReadabilityEnabled on the label to handle cases where > > the > > > system colors don't work? Perhaps that will typically yield white as > > > expected/spec'ed, and it seems like we ought to use readable versions of the > > > system colors anyway. > > > > I don't follow. This code just makes blue buttons look like normal buttons. > > There's no other option right now, except to make blue buttons never be > themed, > > which looks way worse IMO. > > Yeah, I suggest (1) using readable versions of these normal button text colors. > We need readable colors because users with blue text colors won't be able to > read blue text on blue buttons. > > I'm also suggesting (2) possibly removing these new color ids. I'm hoping that > we can just use the normal color ids (like kColorId_ButtonEnabledColor above) > everywhere and still get something legible and close to spec. The buttons aren't blue. Without this patch, they have normal button bg color but white text. With this patch, they have normal button bg color and normal button text. In the future, they could have theme-appropriate bg color and theme-appropriate text color (e.g. if your highlight color is orange, the BlueButton could be orange bg with white text).
On 2014/06/03 00:54:16, Evan Stade wrote: > On 2014/06/02 22:39:44, msw wrote: > > Can you post some screenshots on the bug? > > I could but they would not be interesting. They would just be normal buttons in > place of BlueButtons. It was interesting enough for me to build locally and test this defect, and then come up with a working alternative (better, IMO) solution, not applying the GTK-theme border to these buttons, see <https://codereview.chromium.org/309203002>. I also posted my before/after pictures to the bug. > > Are BlueButtons not blue in the GTK-theme-mode? > > No. > > > If so, why isn't that the defect > > that you're aiming to fix for Issue 375350? > > Because the more pressing defect is the illegible text. > > > Otherwise, if we never want > > BlueButtons to be blue buttons in GTK-theme-mode, then we should probably just > > use LabelButton directly instead of hacking up BlueButton to work correctly as > a > > beige/white gtk-styled button. > > a) we do want BlueButtons to have a special color, and this patch provisions for > that future without actually implementing it (yet) > b) I don't know of a clean way to swap out the entire class based on the native > theme, especially given that the native theme can change. Let's keep the non-GTK BlueButton appearance for now to match spec and keep a legible button. Later, you can explore ways to make the GTK assets blue colored or highlighted in some other way. https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... File ui/views/controls/button/blue_button.cc (right): https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... ui/views/controls/button/blue_button.cc:28: UpdateThemedBorder(); If we want these buttons to be blue, can't we just make BlueButton use the normal Views border, and not apply the GTK-style border in LabelButton::UpdateThemedBorder? Later, if we want to implement blue-tinted (or highlighted) gtk-styled buttons, we can implement that? So, for now all you really have to do is set |border_is_themed_border_| to false before this call, or call SetBorder(CreateDefaultBorder().PassAs<Border>()) instead here to essentially do the same thing.
On 2014/06/03 02:10:09, msw wrote: > On 2014/06/03 00:54:16, Evan Stade wrote: > > On 2014/06/02 22:39:44, msw wrote: > > > Can you post some screenshots on the bug? > > > > I could but they would not be interesting. They would just be normal buttons > in > > place of BlueButtons. > > It was interesting enough for me to build locally and test this defect, and then > come up with a working alternative (better, IMO) solution, not applying the > GTK-theme border to these buttons, see > <https://codereview.chromium.org/309203002>. I also posted my before/after > pictures to the bug. > > > > Are BlueButtons not blue in the GTK-theme-mode? > > > > No. > > > > > If so, why isn't that the defect > > > that you're aiming to fix for Issue 375350? > > > > Because the more pressing defect is the illegible text. > > > > > Otherwise, if we never want > > > BlueButtons to be blue buttons in GTK-theme-mode, then we should probably > just > > > use LabelButton directly instead of hacking up BlueButton to work correctly > as > > a > > > beige/white gtk-styled button. > > > > a) we do want BlueButtons to have a special color, and this patch provisions > for > > that future without actually implementing it (yet) > > b) I don't know of a clean way to swap out the entire class based on the > native > > theme, especially given that the native theme can change. > > Let's keep the non-GTK BlueButton appearance for now to match spec and keep a > legible button. Later, you can explore ways to make the GTK assets blue colored > or highlighted in some other way. "Matching spec" is a misnomer here. There is no spec for GTK theme mode. Using blue in Gtk theme mode looks terrible anywhere that actually respects the GTK theme (e.g. the payments dialog). The screenshot you posted is a part of Chrome that doesn't respect GTK theme mode (the new profile manager). > > https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... > File ui/views/controls/button/blue_button.cc (right): > > https://codereview.chromium.org/288983010/diff/40001/ui/views/controls/button... > ui/views/controls/button/blue_button.cc:28: UpdateThemedBorder(); > If we want these buttons to be blue, can't we just make BlueButton use the > normal Views border, and not apply the GTK-style border in > LabelButton::UpdateThemedBorder? Later, if we want to implement blue-tinted (or > highlighted) gtk-styled buttons, we can implement that? So, for now all you > really have to do is set |border_is_themed_border_| to false before this call, > or call SetBorder(CreateDefaultBorder().PassAs<Border>()) instead here to > essentially do the same thing.
On 2014/06/03 02:14:51, Evan Stade wrote: > On 2014/06/03 02:10:09, msw wrote: > > Let's keep the non-GTK BlueButton appearance for now to match spec and keep a > > legible button. Later, you can explore ways to make the GTK assets blue > colored > > or highlighted in some other way. > > "Matching spec" is a misnomer here. There is no spec for GTK theme mode. Using > blue in Gtk theme mode looks terrible anywhere that actually respects the GTK > theme (e.g. the payments dialog). The screenshot you posted is a part of Chrome > that doesn't respect GTK theme mode (the new profile manager). If you want GTK-themed LabelButtons instead of BlueButtons, then construct LabelButtons instead of BlueButtons, as I suggested earlier. All you have to do is replace the BlueButton constructor calls with factory method calls that optionally return LabelButtons if BlueButton would be broken by LinuxUI. That approach is much more straightforward than trying to work around the defects caused by the lack of GTK-themed BlueButton borders. It's beyond the scope of this CL, but such extensive GTK-theme support is horrible, IMO. It's caused numerous headaches for very little gain, and it'll continue to do so in the future (as eluded to by putting off a GTK-themed blue button and the other TODOs in this bug). This particular aspect of GTK-theme buttons essentially brings back the "native themed" TextButton appearance we had on Windows, which we explicitly decided to replace in favor of the new/Chrome style button assets everywhere. I wish we'd drop support for GTK-style buttons everywhere.
On 2014/06/03 03:08:21, msw wrote: > On 2014/06/03 02:14:51, Evan Stade wrote: > > On 2014/06/03 02:10:09, msw wrote: > > > Let's keep the non-GTK BlueButton appearance for now to match spec and keep > a > > > legible button. Later, you can explore ways to make the GTK assets blue > > colored > > > or highlighted in some other way. > > > > "Matching spec" is a misnomer here. There is no spec for GTK theme mode. Using > > blue in Gtk theme mode looks terrible anywhere that actually respects the GTK > > theme (e.g. the payments dialog). The screenshot you posted is a part of > Chrome > > that doesn't respect GTK theme mode (the new profile manager). > > If you want GTK-themed LabelButtons instead of BlueButtons, then construct > LabelButtons instead of BlueButtons, as I suggested earlier. All you have to do > is replace the BlueButton constructor calls with factory method calls that > optionally return LabelButtons if BlueButton would be broken by LinuxUI. That > approach is much more straightforward than trying to work around the defects > caused by the lack of GTK-themed BlueButton borders. That factory function would depend on the NativeTheme. The NativeTheme can change. Hence you'd have to reconstruct the button every time the NativeTheme changed. Big hassle; ugly. > > It's beyond the scope of this CL, but such extensive GTK-theme support is > horrible, IMO. It's caused numerous headaches for very little gain, and it'll > continue to do so in the future (as eluded to by putting off a GTK-themed blue > button and the other TODOs in this bug). This particular aspect of GTK-theme > buttons essentially brings back the "native themed" TextButton appearance we had > on Windows, which we explicitly decided to replace in favor of the new/Chrome > style button assets everywhere. I wish we'd drop support for GTK-style buttons > everywhere. OK.
On 2014/06/03 21:58:36, Evan Stade wrote: > On 2014/06/03 03:08:21, msw wrote: > > On 2014/06/03 02:14:51, Evan Stade wrote: > > > On 2014/06/03 02:10:09, msw wrote: > > > > Let's keep the non-GTK BlueButton appearance for now to match spec and > keep > > a > > > > legible button. Later, you can explore ways to make the GTK assets blue > > > colored > > > > or highlighted in some other way. > > > > > > "Matching spec" is a misnomer here. There is no spec for GTK theme mode. > Using > > > blue in Gtk theme mode looks terrible anywhere that actually respects the > GTK > > > theme (e.g. the payments dialog). The screenshot you posted is a part of > > Chrome > > > that doesn't respect GTK theme mode (the new profile manager). > > > > If you want GTK-themed LabelButtons instead of BlueButtons, then construct > > LabelButtons instead of BlueButtons, as I suggested earlier. All you have to > do > > is replace the BlueButton constructor calls with factory method calls that > > optionally return LabelButtons if BlueButton would be broken by LinuxUI. That > > approach is much more straightforward than trying to work around the defects > > caused by the lack of GTK-themed BlueButton borders. > > That factory function would depend on the NativeTheme. The NativeTheme can > change. Hence you'd have to reconstruct the button every time the NativeTheme > changed. Big hassle; ugly. Fine, I guess this is the best we can do without actual GTK-style BlueButtons. Post some pictures with your patch applied using Views/GTK themes for both normal and high-contrast-inverse on the bug. https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:241: case kColorId_CallToActionButtonEnabledColor: Rename these kColorId_BlueButton*, or rename BlueButton CallToActionButton. I like the more intent-related name, but consistency is more important until you want to do a wider rename.
screenshots posted https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:241: case kColorId_CallToActionButtonEnabledColor: On 2014/06/03 22:20:41, msw wrote: > Rename these kColorId_BlueButton*, or rename BlueButton CallToActionButton. I > like the more intent-related name, but consistency is more important until you > want to do a wider rename. Done. This reminds me of the part of Earthworm Jim where a quiz show asks you "What color is Jim's red gun?"
Shrug, lgtm https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:241: case kColorId_CallToActionButtonEnabledColor: On 2014/06/03 23:16:12, Evan Stade wrote: > On 2014/06/03 22:20:41, msw wrote: > > Rename these kColorId_BlueButton*, or rename BlueButton CallToActionButton. I > > like the more intent-related name, but consistency is more important until you > > want to do a wider rename. > > Done. > > This reminds me of the part of Earthworm Jim where a quiz show asks you "What > color is Jim's red gun?" FYI, you haven't uploaded the latest patch set with this change.
https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... File chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc (right): https://codereview.chromium.org/288983010/diff/40001/chrome/browser/ui/libgtk... chrome/browser/ui/libgtk2ui/native_theme_gtk2.cc:241: case kColorId_CallToActionButtonEnabledColor: On 2014/06/03 23:24:52, msw wrote: > On 2014/06/03 23:16:12, Evan Stade wrote: > > On 2014/06/03 22:20:41, msw wrote: > > > Rename these kColorId_BlueButton*, or rename BlueButton CallToActionButton. > I > > > like the more intent-related name, but consistency is more important until > you > > > want to do a wider rename. > > > > Done. > > > > This reminds me of the part of Earthworm Jim where a quiz show asks you "What > > color is Jim's red gun?" > > FYI, you haven't uploaded the latest patch set with this change. Done.
ping Ben
lgtm
The CQ bit was checked by estade@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/estade@chromium.org/288983010/60001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: win_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...) win_chromium_x64_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: win_chromium_rel on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)
The CQ bit was checked by estade@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/estade@chromium.org/288983010/80001
Message was sent while issue was closed.
Change committed as 275225 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
