Open Bug 1852790 Opened 2 years ago Updated 1 month ago

Pasting NULL bytes into textarea fails

Categories

(Core :: Widget: Gtk, defect, P3)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 116
Type:
defect

Tracking

()

Status:
ASSIGNED

People

(Reporter: xan, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1852790 [Linux] Get UTF8 text as data r?emilio
48 bytes, text/x-phabricator-request
Details | Review

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

Steps to reproduce:

My users need to paste strings that include NULL characters into Firefox texareas.

Actual results:

The pasted data was cut off at the first NULL byte.

Expected results:

Almost anything else: include the NULL characters, ignore the NULL characters, replace them with the replacement character. Cutting off is the worst thing to do.

I have created a test page that describes and demonstrates the issue:
https://biblionix.xyz/pasting_null_bytes/

Chrome seems to handle the situation without issue.

Background: my users are copying the source of their Amazon "order details" page for processing by my web-based service. Amazon recently started including NULL bytes in this order details file. Of course this is beyond my control!

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Is there any reason not to skip over \x00 bytes in textareas, rather than truncating at such bytes?

How do you get the string with NULL characters to clipboard? I expect you use copy from any other web page? Can you attach exact reproduction steps? It may be an issue with bad string conversion when copy / paste from clipboard, we use UTF-8 and this bug may point to bad encoding.

May you try any older Firefox version? It may be a bug in our clipboard code.
Thanks.

Flags: needinfo?(xan)

What I'm attempting to do in the real world is process HTML from Amazon: I'm attempting to process the order details form to pick out what items were ordered. It works fine, except that the Amazon HTML includes NULL characters.

To reproduce:

Removing the NULL characters is fine, but I don't see any reason to remove all the text after them too.

I'm sorry for the delay in reply, I missed the notification email and only happened to see you had commented here. I appreciate your help.

Flags: needinfo?(xan)

Correction to the above: it's not a form I'm processing in the real world, it's the "here's what you ordered" HTML page.

Where the null character come from? Is that UFT8 string which is wrongly considered as C string? Do you see the same behavior with wl-paste utility? (try to paste null character as utf8 string).

Flags: needinfo?(xan)
Blocks: gtktitlebar
Priority: -- → P3

The NULL characters come from the source of a web page, in just the way they're being delivered via that "HTML" link on the test page.

I tried wl-paste. When I copy the HTML source and then run wl-paste, my terminal shows the text before and after the NULL characters. (I'm not entirely sure whether it includes them or not.) wl-paste | less shows the same. But if I do wl-paste > test.txt, then the resulting file is truncated at the first NULL character. The text after them is not included.

I tried Firefox 32 and observed the same issue. I wasn't immediately able to go farther back, since older versions don't work with the TLS version on this server. I can work around that to go farther back if it would be helpful.

I tried Chrome going back to version 37 and it has what I believe to be correct behavior: it strips out the NULL characters but still includes all the text afterwards.

I've been telling my customers who need to use this feature to install Chrome. :-(

Flags: needinfo?(xan)

What window manager are you using? Using Ubuntu 24.04.2 LTS and XFCE I'm able to copy and paste the entire text. It worked with Firefox release 138.0.1 and with Nightly 140.0a1.

I'm using KDE on Debian stable (bookworm), so I suppose the window manager is Kwin. I am running Wayland now. When first reporting this, I believe I was on bullseye which was Xorg.

I tested Firefox on Windows (via BrowserStack) and the problem appeared all the way back to version 32, the oldest I could easily go.

Flags: needinfo?(stransky)

I think we're hitting wrong text MIME type here where UTF8 is processed as plain C strings.

I can reproduce it. There's the related log:

[Parent 18296: Main Thread]: D/WidgetClipboard ClipboardDataSnapshot::GetDataSync: 7f7f2e6650c0
[Parent 18296: Main Thread]: D/WidgetClipboard nsClipboard::GetNativeClipboardData (clipboard)
[Parent 18296: Main Thread]: D/WidgetClipboard   Flavors which can be imported:
[Parent 18296: Main Thread]: D/WidgetClipboard     text/plain
[Parent 18296: Main Thread]: D/WidgetClipboard     Getting text text/plain MIME clipboard data
[Parent 18296: Main Thread]: D/WidgetClipboard nsRetrievalContextWayland::GetClipboardText(), clipboard Selection
[Parent 18296: Main Thread]: D/WidgetClipboard nsRetrievalContextWayland::WaitForClipboardData, MIME (null)
[Parent 18296: Main Thread]: D/WidgetClipboard   getting TEXT
[Parent 18296: Main Thread]: D/WidgetClipboard clipboard_get_cb() callback
[Parent 18296: Main Thread]: D/WidgetClipboard nsClipboard::SelectionGetEvent (clipboard)
[Parent 18296: Main Thread]: D/WidgetClipboard   selection target text/plain;charset=utf-8
[Parent 18296: Main Thread]: D/WidgetClipboard   providing text/plain data
[Parent 18296: Main Thread]: D/WidgetClipboard   sent 115 bytes of utf-8 data
[Parent 18296: Main Thread]: D/WidgetClipboard   using gtk_selection_data_set for 'text/plain;charset=utf-8'
[Parent 18296: Main Thread]: D/WidgetClipboard OnTextReceived(clipboard) callback
[Parent 18296: Main Thread]: D/WidgetClipboard Request::Complete(), aData = 7f7f2ed5a000, timedOut = 0
[Parent 18296: Main Thread]: D/WidgetClipboard     getting 68 bytes of text.
[Parent 18296: Main Thread]: D/WidgetClipboard     done, mClipboardData = 7f7f2a094650
[Parent 18296: Main Thread]: D/WidgetClipboard SetTransferableData MIME text/plain
[Parent 18296: Main Thread]: D/WidgetClipboard     got text data, length 68
[Parent 18296: Main Thread]: D/WidgetClipboard clipboard_clear_cb() callback
[Parent 18296: Main Thread]: D/WidgetClipboard nsClipboard::SelectionClearEvent (primary)
[Parent 18296: Main Thread]: D/WidgetClipboard nsRetrievalContext::ClearCachedTargetsPrimary()

The problem is that we set UTF8 string in one tab as clipboard source but we paste it in another tab as text/plain which is C string and that's truncated then.

Blocks: gtkclipboard
No longer blocks: gtktitlebar
Flags: needinfo?(stransky)

Also looks like wl-paste correctly pastes clipboard content while Firefox truncates it.

Flags: needinfo?(stransky)

Xan, do you say it's broken on Windows too?

Flags: needinfo?(xan)

Chrome works because it removes all null chars from the page - it ignores them completely. I wonder if Firefox can do the same.

There are two possible fixes on Firefox side:

  1. Ignore null chars when we paste to clipboard (from the HTML page?). I wonder why we paste nullptr to clipboard or show them at all?
  2. Filter out what we get from clibpboard (null UTF-8 can be insterted by third-party app). It can be fixed by getting text as data as Gtk receives all text strings as null terminated.

UTF8 string can contain null characters which can be received by gtk_clipboard_request_text() as it returns C string terminated by null char.
Use gtk_clipboard_request_contents() instead and convert it to UTF16 (internal Firefox string format) directly.

Assignee: nobody → stransky
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(stransky)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #15)

Xan, do you say it's broken on Windows too?

Yes, I observed the same problem on Windows.

Flags: needinfo?(xan)
Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/4bb36ad75e26 [Linux] Get UTF8 text as data r=emilio

Please file a new bug for Windows. Linux one should be fixed by the patch here.

Pushed by chorotan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5211e49f26cb Revert "Bug 1852790 [Linux] Get UTF8 text as data r=emilio" for causing bc failures at browser_bookmark_copy_folder_tree.js

Backed out for causing bc failures at browser_bookmark_copy_folder_tree.js

Backout link

Push with failures

Failure log

Flags: needinfo?(stransky)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #21)

Please file a new bug for Windows. Linux one should be fixed by the patch here.

I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1966443

I also tried it on MacOS, and there does not seem to be a problem there. The NULL bytes are included, which is different from how Chrome handles it, but that isn't a problem for my use case at least.

[task 2025-05-14T10:17:56.316Z] 10:17:56     INFO - TEST-UNEXPECTED-FAIL | browser/components/places/tests/browser/browser_bookmark_copy_folder_tree.js | "toolbar\r\nmainFolder\r\nFolderA\r\nsubFolderA\r\nhttps://example.com/1\r\nhttps://example.com/2\r\nhttps://example.com/3\r\nFolderA\r\nsubFolderA\r\nhttps://example.com/1\r\nhttps://example.com/2\r\nhttps://example.com/3\r\nToolbar shortcut\r\n" == "toolbar\nmainFolder\nFolderA\nsubFolderA\nhttps://example.com/1\nhttps://example.com/2\nhttps://example.com/3\nFolderA\nsubFolderA\nhttps://example.com/1\nhttps://example.com/2\nhttps://example.com/3\nToolbar shortcut\n" -

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:stransky, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Flags: needinfo?(stransky)
Flags: needinfo?(emilio)

Seems like there are test failures to be fixed.

Flags: needinfo?(emilio)

Looks like Windows version on this was also backed out (Bug 1966443).

Flags: needinfo?(stransky)
See Also: → 1966443

I wonder if we need a kind of sanitation of input string instead of the plain UTF8 conversion.

Update: over at the Windows version of this bug, a patch has been posted with description containing " This patch skips NUL bytes on all platforms when adding to the clipboard or when dragging text from Firefox. This normalizes the behavior across platforms"
https://bugzilla.mozilla.org/show_bug.cgi?id=1966443#c15

That might make this bug moot (even though this is the original).

(In reply to Xan Charbonnet from comment #30)

Update: over at the Windows version of this bug, a patch has been posted with description containing " This patch skips NUL bytes on all platforms when adding to the clipboard or when dragging text from Firefox. This normalizes the behavior across platforms"
https://bugzilla.mozilla.org/show_bug.cgi?id=1966443#c15

That might make this bug moot (even though this is the original).

Yes, that may be the best solution here, Thanks!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: