[Editor] Add a color picker with predefined colors for highlighting text (bug 1866434)

[calixteman]

The doorhanger for highlighting has a basic color picker composed of 5 predefined colors
to set the default color to use.
These colors can be changed thanks to a preference for now but it's something which could
be changed in the Firefox settings in the future.
Each highlight has in its own toolbar a color picker to just change its color.
The different color pickers are so similar (modulo few differences in their styles) that
this patch introduces a new class ColorPicker which provides a color picker component
which could be reused in future editors.
All in all, a large part of this patch is dedicated to color picker itself and its style
and the rest is almost a matter of wiring the component.

[calixteman]

/botio-linux preview

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_preview from @calixteman received. Current queue size: 0

Live output at: http://54.241.84.105:8877/644682722003ebf/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.241.84.105:8877/644682722003ebf/output.txt

Total script time: 1.42 mins

Published

• Viewer: http://54.241.84.105:8877/644682722003ebf/web/viewer.html
• Viewer (legacy): http://54.241.84.105:8877/644682722003ebf/legacy/web/viewer.html

[Snuffleupagus]

Something that would really help (and reduce the time it takes me to review this), given the size/scope of these changes, is a high-level overview of what's being changed and why here.
Can you pretty please write a paragraph, or even two, explaining these changes (maybe put it in the commit message as well)?

Skimming this, there's a few things that I'm not totally sure of:

• Do we actually need to "generate" the viewer-UI highlightToolbar?
  Why can't we keep the HTML code in the viewer, to (slightly) lessen the amount of changes here?

• Why are the colors specified in a preference, since that seems to add overall complexity?
  Furthermore, is this intended to be temporary during development/testing (there's no comment about this)?
  Given the new localization-strings, for the colour-names, it doesn't seem (to me) that e.g. the user changing this preference would make a lot of sense?

[Snuffleupagus]

I'm slowly starting to review this, but before looking in detail at the code I've got some observations based on playing with the preview in #17359 (comment) above.

• Nit: There's a typo in the commit message, hightlighting text -> highlighting text.

• Looking at the new editorHighlight viewer-toolbar, the padding feels ever so slightly "off" compared to the existing editor-toolbars:

  • The padding-top value seems to be a little bit too large, resulting in what feels like slightly too much empty space at the top of the new toolbar.
  • When the left-most color is hovered/selected the focus-ring extends "beyond" the left edge of the "Highlight"-label,
    which again seems a little weird.

  

• The new editorHighlight viewer-toolbar probably doesn't handle RTL locales correctly, since the "Highlight"-label is still left-aligned.

  

• The button order on the new "inline" editorHighlight-toolbar seems inconsistent, when compared with the editorStamp-toolbar; note the red outlines in the screen-shot below.
  In my opinion, having the Delete-button "move around" depending on the editor-type doesn't seem great. First of all it just feels inconsistent, and secondly it might lead to users accidentally clicking the Delete-button when moving from one editor-type to another.
  For any button(s) that all editors implement, I really think that it should have the same relative position in all editors.

  

[caseyr28]

Hi @Snuffleupagus - UX chiming in here. Thanks for the review and feedback.

1. editorHighlight viewer-toolbar padding; Agreed, we will make consistent with the other toolbars.
2. Left-most icon alignment; This was designed that intentionally, as otherwise the unselected state would have an indent that would appear off, in my opinion. I am taking some inspiration from the typographic principle of "Hanging punctuation" - obviously these are not all characters, but optically the color-swatch itself should be the main-aligned element.
3. The button order on the new "inline" editorHighlight-toolbar; Agreed, thanks for catching that. To be updated.
4. handle RTL locales; @calixteman let me know if we need to add specs for this.

Thanks

[Snuffleupagus]

One thing that I noticed, which might be on purpose but feels a little bit inconsistent, is that after you'd added a highlightEditor its color can only be changed with the editToolbar-dropdown.
However, trying to change the color from the viewer-toolbar does nothing for a currently selected highlightEditor.

[calixteman]

One thing that I noticed, which might be on purpose but feels a little bit inconsistent, is that after you'd added a highlightEditor its color can only be changed with the editToolbar-dropdown. However, trying to change the color from the viewer-toolbar does nothing for a currently selected highlightEditor.

Yep it's on purpose: the color in the main toolbar is the default color to use.

[Snuffleupagus]

r=me, thank you!

[calixteman]

/botio integrationtest

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Received

Command cmd_integrationtest from @calixteman received. Current queue size: 0

Live output at: http://54.241.84.105:8877/b1bb3b7f2d55957/output.txt

[moz-tools-bot]

From: Bot.io (Windows)

---

Received

Command cmd_integrationtest from @calixteman received. Current queue size: 0

Live output at: http://54.193.163.58:8877/90fc1d49b325552/output.txt

[moz-tools-bot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.241.84.105:8877/b1bb3b7f2d55957/output.txt

Total script time: 5.77 mins

• Integration Tests: FAILED

[moz-tools-bot]

From: Bot.io (Windows)

---

Failed

Full output at http://54.193.163.58:8877/90fc1d49b325552/output.txt

Total script time: 13.93 mins

• Integration Tests: FAILED