1818910 - Clipboard <textarea> after the null character are truncated

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

Description

[15063662]

Attachment: 1.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

(See HTML in the attachment)
The value of <textarea> is text in the front\0\0\0text after
Focus <textarea> and select all.
Excute Copy in context menu.

Actual results:

Text after the null character are truncated.
In the clipboard is text in the front

Expected results:

Text should be copied as it is.
(tested in Chrome)

Comment 1

[15063662]

Attachment: output.gif

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Copy & Paste and Drag & Drop' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Sean Feng [:sefeng]]

Edgar, do you mind check this out? Not sure if this is a bug or just how we handles null characters.

Comment 4

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

I could not reproduce this issue on macOS. It seems that only Windows and GTK are affected. I suspect this is related to how the string data is placed into the system clipboard.

Comment 5

[Sean Feng [:sefeng]]

Okay, thanks. I have Linux running, so I can investigate this on Linux.

Comment 6

[Sean Feng [:sefeng]]

Attachment: WIP: Bug 1818910 - Strip out null characters when getting text from Gtk selection

Comment 8

[Sean Feng [:sefeng]]

So I have some findings about this bug.

For Gtk, the clipboard API is able to store the data after the null characters. Basically if you copy the content, and then run xclip -o -selection primary, it'll display the entire content text in the fronttext after. However, the gtk_clipboard_request_text API can't give you content after the null character (I think because it does some unicode conversion stuff). So I attached a patch which fixes it by removing the null characters from the selection before sending the data to the clipboard.

For Windows, it seems that all it relies on is the OleSetClipboard API which we don't control. I don't see our clipboard API usage reads the data from the selection. So I couldn't do the same fix as I did on Linux to fix Windows.

Now taking a step back, it looks like Chrome doesn't handle this around the clipboard usage, rather it modifies the content of the <input> directly. On Linux, chrome truncates the null character from the input, and chrome replaces the null character with a different character (not sure what it is) on Windows. So Chrome doesn't have this null characters in selection issue at all.

I think this should well-defined in the spec, however I couldn't find anything relates to this.

Edgar, Simon, what do you think?

Comment 9

[Simon Pieters [:zcorpan]]

I don't see anything in the HTML spec that would remove or do anything with null characters for textarea (which means it's non-conforming to truncate or remove null characters). For Chrome on macOS, they are present at least when getting .value:

$0.value
'text in the front\x00\x00\x00text after'

If it's handled differently on Linux/Windows I guess we should file a bug.

Per https://wpt.fyi/results/html/semantics/forms/the-textarea-element/value-defaultValue-textContent.html?label=experimental&label=master&aligned it seems like it's passing for Chrome Linux, though?

Comment 10

[Sean Feng [:sefeng]]

I see..perhaps this is still a Firefox specific bug then.

I also see 'text in the front\x00\x00\x00text after' in Chrome on Windows and Linux. However Firefox displays text in the front\u0000\u0000\u0000text after on Windows and Linux. What does it display on MacOS? Perhaps the unicode null character is causing us trouble?

Comment 11

[Simon Pieters [:zcorpan]]

The U+0000s are not rendered in Chrome but are placeholder boxes in Firefox.

Per https://github.com/w3c/csswg-drafts/issues/8261 it seems there's agreement that they should be rendered, but maybe hasn't shipped yet in Chrome.

Does selection and copy work off of rendered characters in Chromium?

Comment 12

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

(In reply to Sean Feng [:sefeng] from comment #10)

What does it display on MacOS?

I get same result on macOS, i.e. text in the front\x00\x00\x00text after in Chrome and text in the front\u0000\u0000\u0000text after in Firefox.

Comment 13

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

Attachment: test.html

Chrome doesn't render the null character, so copying the selection data might not really put null character into system clipboard. I create this test that try to put string with null character into system clipboard without depending on selection.

Steps:

1. click the input element
2. press ctrl+c to copy.
3. press ctrl+v to paste.
4. check console log.

The behavior I notice is:

• If I do both copy and paste on Firefox, I don't see the issue on macOS, but Linux. (did not test Windows)
• If I do both copy and paste on Chrome, I don't see the issue on both macOS and Linux. (did not test Windows)
• On Linux, if I do copy on Firefox and paste on Chrome, Chrome get full string with null character.
• On Linux, if I do copy on Chrome and paste on Firefox, Firefox get the truncated string.

So it seems like Firefox do put the string with null character into system clipboard correctly, but somehow has an issue on reading string with null character from system clipboard on Linux?

Comment 14

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

(In reply to Edgar Chen [:edgar] from comment #13)

So it seems like Firefox do put the string with null character into system clipboard correctly, but somehow has an issue on reading string with null character from system clipboard on Linux?

Oh, you have mentioned this on comment#8. Since Chrome could read the entire content we put into system clipboard, so I am curious how Chrome handle that.

Comment 15

[Simon Pieters [:zcorpan]]

For rendering U+0000, Gecko normally doesn't do that unless layout.css.control-characters.visible is true (it's false by default on Release), but textarea does regardless of the pref because of this UA style rule: https://searchfox.org/mozilla-central/rev/af78418c4b5f2c8721d1a06486cf4cf0b33e1e8d/layout/style/res/forms.css#147

(Ack :jfkthame for this info.)

Comment 16

[Sean Feng [:sefeng]]

On Linux, if I do copy on Firefox and paste on Chrome, Chrome get full string with null character.

This is brilliant :) I tried to look into how Chrome handles this, however I haven't made any progress yet. I'll try to find some time later to continue this.