Bisect Information:
--------------------
You are probably looking for a change made after 482903 (known good), but no later than 482904 (first known bad).

CHANGELOG URL:
----------------- https://chromium.googlesource.com/chromium/src/+log/8b4643f67dc1c6b142a152aa2b76c771287e3a22..1894d423068be735560e0171922c833c4091b5d1

Suspecting https://chromium.googlesource.com/chromium/src/+/1894d423068be735560e0171922c833c4091b5d1 from the above CL

@ccameron: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Able to reproduce the issue using #62.0.3188.0 on Mac 10.12.6.

Thanks!!

The color picker is picking colors in display space. It isn't converting them back to sRGB when it sends them back.

So, now I need to search back to where the color picker gets its color from and hope that there's a display::Display nearby that we can use for the conversion.

+pfeldman, hubbe, since I'll probably need some input on this.

The color picker's color space is not currently defined. I'd suggest defining it to be sRGB. If this is the case, then color picking ...
- from Chrome windows will be always self-consistent
- on Mac will always be consistent (since colors are consistent on Mac)
- on Linux and Windows there will be mixed bag when picking from other appliations

AFAICT the color picker is only able to pick colors from the web contents area of a window -- not from the whole OS.

If this is the case, then life is quite a bit easier -- we know the color space of the picked color and we can adjust it appropriately.

> I'd suggest defining it to be sRGB.

That sounds fine to me. Self-consistency is the strongest requirement I can think of.

> color picker is only able to pick colors from the web contents area of a window 

confirming this, only from within the web contents.

Thanks for the confirmation. Adding RBS label for M61.

For M61 I want to fix this, but the fix will be to do a color conversion from the ui::Compositor's color space to sRGB directly in DevToolsEyeDropper::HandleMouseEvent. That fix is very small (and not so great software engineering) to be safe for a merge.

For the longer term fix, I would like to add a color conversion API to RenderWidgetHostView::CopyFromSurface. This could take the form of either
- CopyFromSurface's callback specifying the color space that was read in
- Requesting a specific color space to the CopyFromSurface function
I'll canvas around about which would be preferable. Of note is that CopyFromSurface would, in that case, be a draw rather than a readback.

[Bulk Edit]
URGENT - PTAL.
M61 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. 

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M62. Thank you!

Note: We will only have 2 beta releases before Stable promotion. Plan is to cut M61 Stable RC on 08/31/17.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/95fb5ee64154c4213c04c7e713dd16c1d256c5d9

commit 95fb5ee64154c4213c04c7e713dd16c1d256c5d9
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Aug 23 12:50:58 2017

Ensure devtools eye dropper picks sRGB colors

Transform the reported color from the RenderWidetHost's display's
color space to sRGB.

This is sloppy in that the RenderWidetHost's display's color space may
have changed since when the call to CopyFromSurface was made (e.g, the
window moved to another monitor, or the display was reconfigured). The
consequence of using the wrong color space is not worse than the
original bug.

This is a temporary fix to be merged to M61. The long term fix will
require touching lots of files (at the least) and wouldn't suitable for
merge (see crbug.com/758057).

Bug:  756329 
Change-Id: I5e2d2421abaf82f995b7018707ae00aca9915301
Reviewed-on: https://chromium-review.googlesource.com/627857
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496664}
[modify] https://crrev.com/95fb5ee64154c4213c04c7e713dd16c1d256c5d9/chrome/browser/devtools/devtools_eye_dropper.cc

Adding merge request.

This is not a completely trivial merge (at least compared to my other merges which are truly nothing), but is also still very low risk.

I'm okay with merging either now or after a few days on Canary.

This bug requires manual review: We are only 11 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please update the bug with Canary coverage on Monday, 08/28. Thank you.

Rechecked this issue on Chrome version 62.0.3196.0 on Windows 10, Mac 10.12.6, Ubuntu 14.04. Fix is working as intended. Clicking on NTP, does not changes the background color. Adding TE-Verified labels for M62.

P.S: However the color picker moves a bit for the initial clicks. Screen recording attached.

Thanks.!

Deleted: Picker Icon Moves.mov 12.1 MB

Picker Icon Moves.mov 12.1 MB Download

Yes, a small change at each click, due to rounding error, can happen.

The NextAction date has arrived: 2017-08-28

 ccameron@, how is the change looking so far in Canary?

This appears fixed, and I don't see browser crashes that suspicious. I'm up for merging this.

Approving merge to M61 branch 3163 based on comments #17 and #21. Please merge ASAP. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/00b7891be10cb5923b1833e64c324d2ae34a282d

commit 00b7891be10cb5923b1833e64c324d2ae34a282d
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon Aug 28 18:22:43 2017

Ensure devtools eye dropper picks sRGB colors

Transform the reported color from the RenderWidetHost's display's
color space to sRGB.

This is sloppy in that the RenderWidetHost's display's color space may
have changed since when the call to CopyFromSurface was made (e.g, the
window moved to another monitor, or the display was reconfigured). The
consequence of using the wrong color space is not worse than the
original bug.

This is a temporary fix to be merged to M61. The long term fix will
require touching lots of files (at the least) and wouldn't suitable for
merge (see crbug.com/758057).

TBR=ccameron@chromium.org

(cherry picked from commit 95fb5ee64154c4213c04c7e713dd16c1d256c5d9)

Bug:  756329 
Change-Id: I5e2d2421abaf82f995b7018707ae00aca9915301
Reviewed-on: https://chromium-review.googlesource.com/627857
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#496664}
Reviewed-on: https://chromium-review.googlesource.com/638860
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#937}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/00b7891be10cb5923b1833e64c324d2ae34a282d/chrome/browser/devtools/devtools_eye_dropper.cc

Tested the issue using #61.0.3163.71 on Windows 10, Mac 10.12.6, Ubuntu 14.04. Observed Background color is not changing.

Note: Somehow observing the color picker moves a bit for the initial clicks. Please find the attached screen cast.

Adding Verified labels.

Thanks!!

Deleted: Aug 30 2017 2-22 PM.webm 2.7 MB

	Aug 30 2017 2-22 PM.webm 2.7 MB View Download

#9 > > I'd suggest defining it to be sRGB.

> That sounds fine to me. Self-consistency is the strongest requirement I can think of.

Seems fine.  Are our users getting consistent colors for the web's color picker? https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color