1678876 - Clipboard copy issues when an <svg> is within the selection

Status: RESOLVED DUPLICATE of bug 1674763

(Core :: DOM: Selection, defect)

Description

[acheronfail]

Attachment: svg-copy.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

When loading the attached SVG file, select all content in the document (ctrl/cmd + a) and copy it to the clipboard (ctrl/cmd + c).

Then, inspect the clipboard (I use https://evercoder.github.io/clipboard-inspector/ which is an easy way to inspect the text/html portion on the clipboard).

Actual results:

You'll see that the DOM is incorrectly copied. The <ul> tag is duplicated because it seems the recursion level is broken somewhere.

Expected results:

The text/html that was copied should match the structure of the document copied.

Comment 1

[acheronfail]

I've tried looking through the code (very new to hacking on firefox), and my search has narrowed it down to an issue with the selection in:

nsHTMLCopyEncoder::SetSelection in dom/base/nsDocumentEncoder.cpp

I can't seem to find the callers of this function though, and my gdb debugging skills aren't the greatest, I can't seem to get gdb to break on this function call either, so I'm a little stuck so far.

Comment 2

[acheronfail]

When copying the HTML in the attachment, if I log the following:

for (uint32_t i = 0; i < rangeCount; ++i) {
  std::cout << "range[" << i << "]" << std::endl;
  std::cout << "  start = " << aSelection->GetRangeAt(i)->GetStartContainer()->NodeName() << std::endl;
  std::cout << "  end   = " << aSelection->GetRangeAt(i)->GetEndContainer()->NodeName() << std::endl;
}

The output is:

range[0]
  start = BODY
  end   = svg
range[1]
  start = #text
  end   = BODY

This ends up breaking the copied text/html.
If I remove the SVG tag from the attachment and then copy, the log outputs:

range[0]
  start = BODY
  end   = BODY

Which is expected (the selection was of the whole document) and the text/html in the clipboard correctly matches the DOM structure.

---

I'm happy to help out on this with some pointers. (:

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia)]

(In reply to acheronfail from comment #1)

I've tried looking through the code (very new to hacking on firefox), and my search has narrowed it down to an issue with the selection in:

nsHTMLCopyEncoder::SetSelection in dom/base/nsDocumentEncoder.cpp

I can't seem to find the callers of this function though, and my gdb debugging skills aren't the greatest, I can't seem to get gdb to break on this function call either, so I'm a little stuck so far.

Be aware that Firefox runs with e10s, that is, with multiple processes. When adding breakpoints, one needs to ensure to add them to the desired process. For some bugs, like this one, it's convenient to disable e10s (./mach run --debugger=gdb --disable-e10s). Then, all breakpoints will be added to the correct process (because there's only one).

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia)]

Btw., was there a practical use-case which lead to filing this issue?

Comment 5

[Mirko Brodesser (:mbrodesser-Igalia)]

acheronfail: a similar issue occurs when not wrapping the <svg> in <ul> and <li>:
<g> is duplicated. Note that <svg> <image href="x.png"</image></svg> works. Presumably, because <image> is by default not styled as user-select: none. See bug 1674763#c7 and the other comments there for more details.

I'm happy to help out on this with some pointers. (:

See bug 1674763#c8 for an idea how to fix this.

Comment 7

[acheronfail]

(In reply to Mirko Brodesser (:mbrodesser) -- away until 2021 from comment #4)

Btw., was there a practical use-case which lead to filing this issue?

Yes, using Atlassian's Confluence product (they have a rich WYSIWYG editor) means if you copy and rich content which includes SVG symbols then the clipboard is broken. It means you can no longer copy & paste in that product in Firefox, and have to use another browser instead. :(