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

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

Hsin-Yi, can you delegate as appropriate?

Talked with Masayuki, he will take a look.

Thanks Joel and Anne.

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

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.

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.

https://hg.mozilla.org/mozilla-central/rev/c5e7322c11b4

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

Absolutely. Looks like that there are some victims actually.

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

https://hg.mozilla.org/releases/mozilla-esr68/rev/7f6aa079d933

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.