Closed Bug 1814345 Opened 1 year ago Closed 1 year ago

[Gmail] Text color selection is not respected

Categories

(Core :: DOM: Editor, defect, P1)

Desktop
All
defect

Tracking

()

RESOLVED FIXED
111 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox109 --- unaffected
firefox110 --- unaffected
firefox111 + verified

People

(Reporter: oardelean, Assigned: masayuki)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(2 files)

Notes

  • This does not reproduce in Chrome. Please see the attached recording for more details.

Found in

  • Nightly 111.0a1;

Affected versions

  • Nightly 111.0a1;

Tested platforms

  • macOS 12;
  • Windows 10;
  • Ubuntu 22;

Affected platforms

  • macOS 12;
  • Windows 10;
  • Ubuntu 22;

Unaffected platforms

  • N/A;

Steps to reproduce

  1. Launch Nightly and go to http://mail.google.com .
  2. Login with a valid account.
  3. Click on the “Compose” button to open a new e-mail window.
  4. From the editor, select any text color.
  5. Write something in the e-mail.

Expected result

  • Text color selection is respected.

Actual result

  • Text color selection is not respected.

Regression range

Set release status flags based on info from the regressing bug 1811161

:masayuki, since you are the author of the regressor, bug 1811161, could you take a look?

For more information, please visit auto_nag documentation.

Odd, Gmail might use CSS color value. I'll fix this tomorrow.

Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Flags: needinfo?(masayuki)
Priority: -- → P1

I see, it's tricky.

Gmail calls document.execCommand("forecolor") with setting styleWithCSS to true. At this time, style editor preserves the color with rgb(..., ..., ...) style value. However, at typing text, styleWithCSS is set to false. Therefore, the CSS style color value is set to <font color>. Okay, we need to normalize the value when we pick the preserved style's color up.

Gmail sets styleWithCSS to true before setting foreColor, then, sets
styleWithCSS to false before user typing text. Currently, we normalize
given color value to a proper value for current styling mode, and we have not
assumed that the mode is changed during preserving the style.

For solving this issue, HTMLEditor::AutoInlineStyleSetter::ApplyStyle should
normalize the given value again if the value is not proper for
<font color="..."> (at this moment, the color value is normalized to #XXXXXX
style or rgb(n, n, n) or rgba(n, n, n, n), therefore the check is simple in
this patch).

Then, I realized that according to editing/run/forecolor.html result [1],
the other browsers accept CSS color value as the parameter of foreColor
command. Therefore, this patch also allows it, thus, this patch fixes a lot of
WPT failures.

  1. https://wpt.fyi/results/editing/run/forecolor.html%3F1-1000?sha=95f9b15d9a&label=master&max-count=1&view=subtest

Depends on D168179

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/9b0a20769286
Make the style setter re-normalize color value when setting `<font color="...">` r=m_kato
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/38321 for changes under testing/web-platform/tests

The bug is marked as tracked for firefox111 (nightly). However, the bug still has low severity.

:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Flags: needinfo?(htsai)
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch
Upstream PR merged by moz-wptsync-bot

Verified on Nightly 111.0a1(build ID: 20230203091639) on macOS 12, Windows 10, Ubuntu 22.

Flags: needinfo?(htsai)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: