EyeDropper API

[ipopescu93]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: EyeDropper API
• Specification or proposal URL: https://wicg.github.io/eyedropper-api/
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

TAG review: w3ctag/design-reviews#587
Chrome Status entry: https://chromestatus.com/feature/6304275594477568

Thanks!

[arayaryoma]

I'm curious about this too.

Chrome has announced to ship this feature.

Intent to Ship: EyeDropper API
https://groups.google.com/a/chromium.org/g/blink-dev/c/rdniQ0D5UfY/m/Aywn9XyyAAAJ

[annevk]

I think overall this seems reasonable. There's a bit of an open question with regards to how much UI is needed to get the user to reveal a color on their screen. Is an overlay enough (a la Fullscreen) or do we want to have the user explicitly confirm they want to share the color with the page? The former is probably more desirable for drawing applications, but might be problematic without something like cross-origin isolation as suggested in WICG/eyedropper-api#13 as it would make stealing cross-origin pixels easy-ish.

It seems Chromium decided to ship this (it works on Canary at least) without such issues being resolved. Not sure if that was intentional? cc @mikewest

[ipopescu93]

thanks @annevk! There are some mitigations currently in place to prevent stealing cross-origin pixels. We are also going to monitor the use of this API in the wild for abuse to see if any follow-up mitigations are needed.

[zcorpan]

@sefeng211 and I looked at the spec. Here are our concerns/questions so far:

• Only sRGB is supported, but should support wide gamut
  • Also see Allow <input type="color"> to give an alpha channel and/or colors beyond sRGB? whatwg/html#3400
• Security: steal cross-origin pixels
  • Same-origin policy violation WICG/eyedropper-api#13
  • The PoC doesn’t seem so compelling. Without being able to pick pixels outside your origin, the functionality is as limited as a polyfill.
• Privacy: :visited leak
  • Same-origin policy violation WICG/eyedropper-api#13 (comment)
  • PoC: An image editor could provide an eyedropper, and when activated overlay the entire UI with a link with :visited { background-color: rgba(0, 0, 0, 0.05); }. When the user has picked a color, the page should know where the pointer is and therefore whether the link was visited.
  • Style all links as unvisited when the eyedropper is open?
  • Filed Leaks browser history from :visited color WICG/eyedropper-api#34
• No integration with <input type=color> and showPicker()
  • We could add something like <input type=color eyedropper onchange="..." oncancel="...">. Is a separate API necessary?
  • Filed Consider extending <input type=color> instead WICG/eyedropper-api#35

[yisibl]

I'd like to add that it would also be useful to provide an option to show the current color value(HEX,RGB etc.). This is provided in the Eyedropper in Firefox DevTools.

<input type="color" eyedropper format="hex">

Chrome shows it as rgb, and when you open Eyedropper's popup, pressing the spacebar toggles whether the color value is shown or not.

[StephenHaney]

Just to add a few use case examples (we make design tools in the browser)

1. We'd definitely need wide gamut and for it to "convert down" accurately. We probably won't be able to use it if it assumes SRGB and gives incorrect values on wide gamut screens.

2. We would also make use of showing the current color code with the reticle.

Ideally you could specify the format. See this example from Figma's color picker. I last used HSL so it's showing me HSL codes. Right now Chrome always shows RGB.