Closed Bug 1778091 Opened 5 months ago Closed 5 months ago

Highlight text color is not preserved after pressing Enter in yahoo mails

Categories

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

defect

Tracking

()

VERIFIED FIXED
104 Branch
Tracking Status
relnote-firefox --- 104+
firefox-esr91 --- unaffected
firefox-esr102 --- wontfix
firefox102 --- wontfix
firefox103 --- wontfix
firefox104 --- verified

People

(Reporter: phorea, Assigned: masayuki)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Found in

  • Firefox 103 beta 4

Affected versions

  • Firefox 102 (RC and ESR)
  • Firefox 103 beta 4
  • latest Nightly 104.0a1 2022-07-04

Affected platforms

  • Win 10 64-bit
  • Ubuntu 22
  • OSX 10.14.6

Steps to reproduce

  1. Access the following website: https://mail.yahoo.com/ and login
  2. Compose a new email
  3. Select Text color option from the bottom of the new email composition
  4. Select a highlight color and start typing
  5. Press Enter

Expected result

  • Highlight color is preserved after pressing Enter

Actual result

  • Highlight color is applied only for the first row, then it changes to the default one

Regression range

I created an account, and tried to compose a new email with the default settings, but I cannot reproduce it with the STR. Do you still reproduce it?

It could be fixed by the Yahoo side? (bug 1730429 aligns the behavior to the other browsers.)

Flags: needinfo?(petruta.rasa)
Attached image outlook.gif

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: ~6/29) from comment #1)

This reproduces on all Firefox versions since bug 1730429 landed.

It also reproduces on outlook mail, please see the attachment (I will provide the credentials we use for outlook on a private message).

Flags: needinfo?(petruta.rasa)
Has STR: --- → yes
Summary: Highlight text color is not preserved after pressing Enter in yahoo mails → Highlight text color is not preserved after pressing Enter in outlook and yahoo mails

Thank you. I took a mistake. I checked with foreground color, not background color. I managed reproduce this too.

Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Priority: -- → P1

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

Sigh, I got the expected result with raw DOM test cases. So, this could be caused by that Gecko runs a UA specific path in Outlook and Yahoo! Mail.

Oh, I see. This is what the minimized testcase.
https://jsfiddle.net/d_toybox/xwa91u4j/3/

At the post-processing here, the DOM tree becomes:

<span style="background-color:xxx">foo</span></div>
<div><span style="background-color:xxx">{}<span><br></div>

Then, the <span> is removed.

However, Chrome creates the new paragraph as:

<div><span style="background-color:xxx">{}<br><span></div>

So, perhaps, we should move the invisible <br> into the <span> before checking if it's removable.

It seems that the Outlook issue is another bug.

Summary: Highlight text color is not preserved after pressing Enter in outlook and yahoo mails → Highlight text color is not preserved after pressing Enter in yahoo mails

I realize that this bug is not reproducible if I test it with list items.

The symptom is different in Yahoo! Mail and Outlook from point of view of the DOM tree result. However, I found a useful utility method CopyLastEditableChildStylesWithTransaction which is used by HandleInsertParagraphInListItemElement and it fixes both Yahoo! Mail and Outlook, so using it must be the safest way to uplift.

Hmm, CopyLastEditableChildStylesWithTransaction has some problems. So it's not good to use in a patch for uplifting to ESR...

In Yahoo! Mail, the paragraph has <br> after <span> element which has
background-color. In this case, Gecko creates the following DOM tree after
splitting the paragraph:

<div><span>foo</span></div><div><span></span><br></div>

Then, the empty <span> in the right paragraph will be removed by the
post-processing. However, in this case, the inline element is required for
preserving the style continued from the previous paragraph.

In this case, we should move the <br> element into the <span> to make
it non-empty and avoid it to be removed. This is compatible with Chrome.

The patch will fix the similar issue in Outlook too. However, it might be not safe to uplift in to ESR since it changes our traditional behavior. I think that it's safe to fix it in ESR102 after shipping the fix in the release channel.

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/5f2fe4601a9e
Make `HTMLEditor` move invisible `<br>` element into the empty inline element after splitting a paragraph at end r=m_kato
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34787 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
Flags: in-testsuite+

Verified as fixed across platforms using Firefox 104 beta 5.

Status: RESOLVED → VERIFIED

Release Note Request (optional, but appreciated)
[Why is this notable]:
Regression in major web app (Yahoo Mail (this bug) and Outlook (bug 1778249))
[Affects Firefox for Android]:
Not sure whether they use same UI for mobile, but if in the desktop mode, it should be reproducible.
[Suggested wording]:
Highlight color is preserved correctly after typing Enter in the mail composer of Yahoo Mail and Outlook.
[Links (documentation, blog post, etc)]:
Nothing.

relnote-firefox: --- → ?
Blocks: 1780140
No longer depends on: 1780140
You need to log in before you can comment on or make changes to this bug.