Closed Bug 1646457 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: DOM: Serializers, defect)

defect

Tracking

()

RESOLVED INVALID
Webcompat Priority ?
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix
firefox79 --- affected

People

(Reporter: clara.guerrero, Assigned: mbrodesser-Igalia)

References

(Blocks 2 open bugs, )

Details

Attachments

(1 file)

Attached video 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.

Summary: Copying two consecutive columns from one nline editor to another is not working properly. → Copying two consecutive columns from one online editor to another is not working properly.

Do we have a meta bug for collecting these?

Severity: -- → S3
Component: DOM: Selection → DOM: Serializers
Flags: needinfo?(mbrodesser)

(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.

Flags: needinfo?(mbrodesser)

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.

Summary: Copying two consecutive columns from one online editor to another is not working properly. → Copying table from one online editor to another is not working properly.
Webcompat Priority: --- → ?

The missing clipboard flavors remind of bug 1665659, c4.

See Also: → 1665659
Assignee: nobody → mbrodesser

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.

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.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: