Bug 167959 - The formatForeColor event fired by the touch bar when changing color sends the color in rgb(x, y, z) format instead of hex.
Summary: The formatForeColor event fired by the touch bar when changing color sends th...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: Safari Technology Preview
Hardware: Mac macOS 10.12
: P2 Normal
Assignee: Wenson Hsieh
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-02-07 14:32 PST by charleyroy
Modified: 2019-02-06 09:19 PST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description charleyroy 2017-02-07 14:32:51 PST
Steps to reproduce:

1. Go to https://jsfiddle.net/v79uznt7/1/
2. Open JS console
3. Put cursor in the editable body
4. Use the touch bar to set the color of the text

Observe that e.data is sent as "rgb(x, y, z)"

This is inconsistent with the spec for Input Events (https://w3c.github.io/input-events/) which states that `If the inputType is "formatBackColor" or "formatFontColor" the value of data is to be the hex digit value of the proposed color.`

While the formatForeColor event is not specified in the Input Events spec, it would be nice to be consistent on how this data is represented across all events. Secondly, why is formatForeColor being used and not formatFontColor?
Comment 1 Radar WebKit Bug Importer 2017-02-08 10:55:55 PST
<rdar://problem/30424022>
Comment 2 Wenson Hsieh 2017-08-23 21:50:20 PDT
Hey Dominic!

Indeed, the way WebKit currently serializes colors is definitely not consistent with the spec (https://w3c.github.io/input-events/index.html). However, I'm not sure there's a compelling reason that this should be in #RRGGBB format, as opposed to the color format used for computed style, which would be able to capture a broader range of colors (e.g. transparent colors, and even colors in an extended color space). I proposed this spec tweak to Johannes in https://github.com/w3c/input-events/issues/67, and it looks like he's okay with changing the spec to limit colors to RGB and RGBA for now, which would be consistent with our current behavior. The rich text controls on the touch bar don't provide a way to specify deep colors at the moment, so I think all choosable colors should fall into RGB or RGBA.

Does this sound reasonable to you?
Comment 3 charleyroy 2017-08-24 07:10:49 PDT
Sounds good to me!
Comment 4 Wenson Hsieh 2017-09-05 14:35:35 PDT
An update: Johannes tweaked the input events spec so that the `data` attribute now allows for an rgb function in https://github.com/w3c/input-events/commit/95b1b4802a1967ef14b9aff1a0fa005c7857015d. I think we can now close this bug as Invalid.

(Also, I've renamed formatForeColor => formatFontColor earlier, in a separate patch).
Comment 5 Lucas Forschler 2019-02-06 09:19:03 PST
Mass move bugs into the DOM component.