1646457 - Copying table from one online editor to another is not working properly.

Status: RESOLVED INVALID

(Core :: DOM: Serializers, defect)

Description

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Attachment: two columns.mov

Affected versions]
release 77.0a1,
beta 78.0b8 (64-bit),
nightly 79.0a1 (2020-06-17) (64-bit)

[Affected platforms]
( macOS 10.14 (Mojave))

[Steps to reproduce]

1- Launch the Firefox Browser and visit https://en.wikipedia.org/wiki/Game_of_Thrones or https://www.w3schools.com/html/html_tables.asp
2- Open https://docs.google.com/spreadsheets and https://onedrive.live.com/, as well as a WYSWYG editor such as http://results.totallympics.com/forum.php?mod=post&action=newthread&fid=37
3- Open online html editor such as https://html-online.com/editor/
4- Select table from 1st step and copy in online editor in step 3
5- Select any desired amount of columns from the table in online editor, and copy.
6- Paste it in open tabs (from step 1 and 2)
7- Notice that table is pasted almost successfully only in one drive spreadsheet (notice that second column is misaligned starting on second row) but other speadsheet will just copy one single cell.

[Expected result]
Table should be pasted accordingly

[Actual result]
Selection pasted is not correct.

If repeating steps in chrome this won't occur as selection and copy works differently.

Comment 1

[Henri Sivonen (:hsivonen)]

Do we have a meta bug for collecting these?

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to Henri Sivonen (:hsivonen) from comment #1)

Do we have a meta bug for collecting these?

Oops. It's already blocking a meta bug.

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia)]

This is not a duplicate of bug 1639972.

Interestingly, the "text/plain" flavor seems correct:

"text/html" flavor:

<meta http-equiv="content-type" content="text/html; charset=utf-8">Contact

"text/plain" flavor:

Contact	Country
Maria Anders	Germany
Francisco Chang	Mexico

Moreover, the "text/_moz_htmlcontext", "text/_htmlinfo" flavors are missing, which I don't know why.

When selecting the whole table, this works on Chrome, but not in Firefox. Tested on Ubuntu 18.04.

Comment 4

[Mirko Brodesser (:mbrodesser-Igalia)]

The missing clipboard flavors remind of bug 1665659, c4.

Comment 5

[Mirko Brodesser (:mbrodesser-Igalia)]

Pernosco session.

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia)]

Current working hypothesis: TextEditor::Copy (called from EditorEventListener::KeyPress) fails somewhere.

DataTransfer::SetData is one of the inner stack frames of TextEditor::Copy, and for the flavor "text/html" it's called with the string of the first selected table cell.
It seems it's called via some JS fromTextEditor::Copy, so the next step is to determine from where exactly.

It seems filling the clipboard is done by some JS of the website. At least it calls Selection::Stringify for the "text/plain" flavor.
Still need to figure out how the clipboard content for "text/html" is generated. Presumably, it's generated from the first range of the Selection, because that corresponds to the exported content.

Comment 7

[Mirko Brodesser (:mbrodesser-Igalia)]

The clipboard is indeed filled from the JS of the website:

            f = function(a, c, d) {
                if (!e(a)) return !1;
                try {
                    return a.clearData(), a.setData("text/html", c), a.setData("text/plain", d), a.setData(b.internalHtmlMime(), c), !0
                } catch (a) { 
                    return !1
                }
            },

I couldn't figure out how the value for the "text/html" flavor is generated, but the JS could do anything, of course.

The above JS uses an older version of TinyMCE:

var tinyMCEPreInit = {
    base: '/editor/tinymce4_6_5',
    suffix: '.min'
}; // 4.6.5 (2017-08-02)

This is fixed in a newer version of TinyMCE (which for instance runs at https://www.tiny.cloud/docs/demo/full-featured/): 5.4.2-90.

In the newer version, the generated "text/plain" flavor misses linebreaks, but that's a separate issue.

Closing this ticket, because it doesn't look like a bug in Gecko.