Closed Bug 1582215 Opened 5 months ago Closed 5 months ago

Pasting formatted text with bulleted list results in bad paste or tab crash

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
thunderbird_esr60 --- unaffected
thunderbird_esr68 --- affected
firefox-esr60 --- unaffected
firefox-esr68 71+ verified
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- verified

People

(Reporter: joel, Assigned: masayuki)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(3 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  1. Create a bulleted list in a Google Docs document with two items. It does not matter if the two items are at the same level, or if one is a sub-bullet of the other. (Here is the exact document that I can reproduce with: https://docs.google.com/document/d/1Ubo-ntJvXAwz3reWk_8vbjVsGJvbu4p2vUEOp4_UGg4/edit)
  2. In Gmail, start composing a new email, and create a bulleted list in the email.
  3. Copy the items from the Google Doc, with the start of the highlight just after the first bullet point, and the end of the highlight at the end of the second item.
  4. Paste these items into the list in the Gmail email.

I was able to reproduce this on macOS on both my Nightly release (70.0a1 (2019-08-28)) and my regular Firefox release (68.0.2). I could not reproduce this in either Chrome or Safari, nor if I mixed Chrome/Safari and Firefox (e.g. copy in Chrome, paste in Firefox, and vice versa).

Actual results:

One of two things can happen: either the bullet point that you are pasting on is deleted and nothing is actually pasted, or the tab just straight up crashes.

Expected results:

The bulleted list should be pasted into the email.

Hi @joel, tested the issue on a Mac OS X 10_14_5 using following FF versions: nightly 71.0a1, beta 70.0b10, release 69.0.1 - the issue cannot be reproduced on none on this versions. Send please an about:support report. You have any other pref /settings modified ?
I will set a component for it, if isn't the right one please fell free to modify.
Regards,
Liviu

Component: Untriaged → Serializers
Product: Firefox → Core
Flags: needinfo?(joel)

Reproduced: https://crash-stats.mozilla.org/report/index/dd05fa5d-2637-4c22-bec8-6394e0191014. Thanks Joel!

Hsin-Yi, can you delegate as appropriate?

Status: UNCONFIRMED → NEW
Component: Serializers → Editor
Ever confirmed: true
Flags: needinfo?(joel) → needinfo?(htsai)
Keywords: crash
Version: 70 Branch → Trunk

Talked with Masayuki, he will take a look.

Thanks Joel and Anne.

Flags: needinfo?(htsai) → needinfo?(masayuki)

This is a regression of bug 1408125 (since 59).

Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Flags: needinfo?(masayuki)
OS: Unspecified → All
Regressed by: 1408125
Hardware: Unspecified → All
Keywords: regression
Priority: -- → P2

Here is the bug:
https://searchfox.org/mozilla-central/rev/17756e2a5c180d980a4b08d99f8cc0c97290ae8d/editor/libeditor/HTMLEditorDataTransfer.cpp#498-500

              if (pointToInsert.GetContainer()->GetParentNode()) {
                DeleteNodeWithTransaction(
                    MOZ_KnownLive(*pointToInsert.GetContainer()));
                pointToInsert.Set(pointToInsert.GetContainer());
              }

After removing a node (pointToInsert.GetContainer()), sets pointToInsert to at the removed node. I.e., pointToInsert is enclosed into the node, i.e., not in the DOM tree. So, we need to cache the original grandparent and it should be set to the grandparent.

Too late for a fix in 70 but we can still take a patch for 72 and likely 71.

When inserting <li> elements into <ul>, <ol> or <li> element,
HTMLEditor::DoInsertHTMLWithContext() removes unnecessary empty <li>
elements at insertion point. At this time, we've computed next insertion
point with removed <li> element. Therefore, insertion point goes out
from the DOM tree. This patch makes it compute new insertion point before
removing each empty <li> element.

Additionally, this patch adds some WPT data for testing this case. I verified
that Chrome passes the new tests too.

Adding the signature in comment #2 to the bug. This signature is already reported in bug 1490469 which has a testcase to reproduce the crash but the work is being done here, should me dupe one to the other?

Given the low volume of crashes, I am marking it as fix-optional for 71.

Crash Signature: [@ mozilla::HTMLEditor::DoInsertHTMLWithContext]

No, bug 1490469 is different bug. Even with the patch, the crash occurs.

Ah, but after fixing this bug, the stack is changed. After fixing this bug, the testcase causes stack overflow due to infinite loop of mutation event listener.

Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/c5e7322c11b4
Make `HTMLEditor::DoInsertHTMLWithContext()` compute new insertion point before removing unnecessary `<li>` elements r=m_kato
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/19752 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Flags: in-testsuite+
Upstream PR merged by moz-wptsync-bot

Is this something we should consider uplifting to ESR68? It would need a rebased patch if so.

Flags: needinfo?(masayuki)

Absolutely. Looks like that there are some victims actually.

Flags: needinfo?(masayuki)
Attached patch Patch for ESR68Splinter Review

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Not a security bug, but there are some crash reports.
  • User impact if declined: When user pastes list items in Google Docs, they may meet crash or see odd result.
  • Fix Landed on Version: 71
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch just invalidate wrong child of pointToInsert with AutoEditorDOMPointChildInvalidator.
  • String or UUID changes made by this patch: none
Attachment #9107156 - Flags: approval-mozilla-esr68?
Comment on attachment 9107156 [details] [diff] [review]
Patch for ESR68

Crash fix, let's take this for 68.3esr.
Attachment #9107156 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Reproduced the issue on affected Release 70 on MacOS 10.13.
Verified-fixed on the latest Firefox Beta 71 and 68.3.0esr on MacOS 10.13

The bullet formatted content is properly copy pasted in a mail which already has a bullet.
Tabs will not crash after copy-pasting the provided formatted text in Comment 0 in a new mail with bullet formats.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.