Closed Bug 1968744 Opened 3 months ago Closed 2 months ago

Text pasted through Ctrl+C/Ctrl+V from Total Commander has additional content

Categories

(Core :: Widget: Win32, defect, P1)

Product:
Core
Component:
Widget: Win32
Version:
Firefox 140
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox139 --- unaffected
firefox140 + disabled
firefox141 + disabled

People

(Reporter: reviler853, Assigned: handyman)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

2025-05-28_07h17_49.png
7.99 KB, image/png
Details

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

Steps to reproduce:

  1. Used Firefox 140b.1 (64bit).
  2. Copied some Japanese text from Total Commander Lister plugin (text viewer). This specific because copying from AkelPad text editor works fine. Also it's not TC Lister plugin's fault since pasting the same text into the latter editor or windows Notepad work fine.
  3. Pasted it anywhere in the browser (search box/url bar/some site's edit box).

Actual results:

There some garbage characters appear not contained in the pasted text that look like some unrealated program's previous buffer.

Expected results:

Text copied unaltered without any garbage added.

Copied some Japanese text from Total Commander Lister plugin (text viewer).

What is exactly the extension? Do you see the problem only copying from this extension?

Can you provide a screenshot of the text you copy (and the text you copy) and the result in Firefox?

Flags: needinfo?(reviler853)

It's default viewer plugin shipped with Total Commander.
Here's simple string copied and pasted: https://i.ibb.co/bgzPJdTy/220307.png
It shows a single \0 character at the end of the string now which was not present in the original in any way (not in the binary dump of the file I copied from nor visible anywhere else I past it) but some strings show much more of such characters. Like an entire path I accessed in some other program.

Flags: needinfo?(reviler853)

Trying to see if webextensions folks can help debugging or redirect.

Product: Firefox → WebExtensions
Summary: Text pasted through Ctrl+C/Ctrl+V pastes some previous buffer data → Text pasted through Ctrl+C/Ctrl+V from Total Commander has additional content

I tried a few other apps, and it seems the text is copied and pasted correctly. For now, I only see such artifacts when copying from Total Commander's Lister. And it doesn't seem a memory bug, since I restarted the system and the issue persists. Also it wasn't in 139 at least as I only found it after updating Firefox to 140 and I copy text rather often.

(In reply to reviler853 from comment #4)

Also it wasn't in 139 at least as I only found it after updating Firefox to 140 and I copy text rather often.

That might be very useful information. Could you try running mozregression to help to identify the issue, if you know it worked in 139?
https://mozilla.github.io/mozregression/quickstart.html

Hello,

I did a bit of digging and installed Total Commander. I found out the Lister plugin mentioned in Comment 0 is an add-on built-in with Total Commander and has no relation to Firefox webextensions. So the bug should be moved somewhere else.

Now regarding the actual bug, I opened some random text files in Lister (F3 key), selected some strings shown in Lister and copied them via Ctrl+C. I then pasted the copied content in Firefox in the address bar via Ctrl+V. The strings were pasted without extra characters at the end or anywhere in between.

However, I then opened a random non-text file in Lister and copied/pasted a string in Firefox. The file was an .xpi and the string I copied looks like this in Lister - PK. . . . ômDJ© . . öü. U. . META-INF/mozilla.rsaÝ—y8”}ÛÇÍbˆ. . ;cÍ:Æ\cI!{¨n. The pasted string looked different, with some extra characters. See screenshot for more details.

However, I believe the results I obtained have something to do with the encoding of the file though and not anything else, so the result I got may not be valid.

Tested on the latest Release (139.0/20250522210034), Beta (140.0b1/20250526170029) and Nightly (141.0a1/20250527164239) under Windows 10.

Attached image 2025-05-28_07h17_49.png —

I tried the 139.0b9 build of the Firefox Developer Edition that I use, and it worked fine.
I also tried it on a clear profile of 140.0b1, and it still bugs like that.
So, it may have something to do with the encoding, but the fact that it worked fine before remains.

Here's last hashes from about:buildconfig:
c42f704bd6c40f1f596ffbbb248aa816380e0697 = broken
ce39a72e138e3e522d58de0e93c89083b9cedf07 = works

Component: Untriaged → DOM: Copy & Paste and Drag & Drop
Product: WebExtensions → Core

(honestly not sure if DOM: Copy & Paste and Drag & Drop is the right place, this might be more of an OS integration bug)

If someone can run mozregression, that would be very helpful to find the right place.

I checked and it also works fine on 139.0b10 with 5ff373e38736b97efb07298b51f68d44ca45b62f hash.

This might be a similar issue to bug 1968267.

See Also: → 1968267

reviler853, do you mind to run it with https://mozilla.github.io/mozregression/? It'd be super valuable to us because we can bisect it to the exact revision that caused this bug.

Flags: needinfo?(reviler853)

Sorry, mozregression didn't want to run correctly in my case because I tired it inside a sandbox.
Something about not finding some .png (it seemed to fail to unpack the downloaded snapshot .zip somehow).
And I don't want to run multiple beta Firefox versions on my only working system.
Is there some commit it can be related to? I can download snapshots before and after it and try manually if I can.

Flags: needinfo?(reviler853)

Also, is it more granular than normal beta releases? I tested major ones and it's somewhere between 139.0b10 (works) and 140.0b1 (bugged).

Mozregression can point you to a specific change, or a small set. Yours includes over a thousand, since it's a major version jump
https://hg-edge.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=5ff373e38736b97efb07298b51f68d44ca45b62f&tochange=c42f704bd6c40f1f596ffbbb248aa816380e0697

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

This might be a similar issue to bug 1968267.

Bug 1968267 is fixed, could you try if you can still reproduce this on latest Nightly? Thank you.

Flags: needinfo?(reviler853)

(In reply to Edgar Chen [:edgar] from comment #16)
Is this in the 140 beta branch already? I'll try as soon it hits it.

Flags: needinfo?(reviler853)

It seems bug 1968267 was fixed in b4 but I still see this on b5:
https://i.ibb.co/99HYJN0s/120720.png

And if I paste this だが (I deleted all wrong stuff after inserting this) into search box it looks like this:
https://i.ibb.co/C3wZ5dRy/121515.png

Hi David, I suspect this is a regression of bug 1966443, but bug 1968267 doesn't help. Could this be a duplicate of bug 1969820, or perhaps something else? Thanks!

Flags: needinfo?(davidp99)

Allowing \0s in a Windows clipboard was an extremely bad idea. The official specification state that the a null character signals the end of the data, and most Windows programmers probably expect it to behave this way. See CF_TEXT/CF_UNICODETEXT in https://learn.microsoft.com/en-us/windows/win32/dataxchg/standard-clipboard-formats

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

Hi David, I suspect this is a regression of bug 1966443, but bug 1968267 doesn't help. Could this be a duplicate of bug 1969820, or perhaps something else? Thanks!

Yeah, I'm going to have to undo this approach. I'll instead need to do the copy in bug 1966443 differently than the other platforms, but that should be fine.

Assignee: nobody → davidp99
Component: DOM: Copy & Paste and Drag & Drop → Widget: Win32
Flags: needinfo?(davidp99)
Severity: -- → S3

Setting Fx140 to disabled since the regressor was backed out of beta
https://bugzilla.mozilla.org/show_bug.cgi?id=1966443#c12

status-firefox140: affected → disabled

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

The bug is marked as tracked for firefox141 (nightly). However, the bug still has low severity.

:gcp, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Flags: needinfo?(gpascutto)

Needs a fix or backout on Nightly too then.

Severity: S3 → S2
Flags: needinfo?(gpascutto)
Priority: -- → P1

Updating the Fx141 flag since the regressor was backed out of Nightly too
https://bugzilla.mozilla.org/show_bug.cgi?id=1966443#c13

status-firefox141: affected → disabled

In 140.0b9 I don't see the bug anymore.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #26)

Needs a fix or backout on Nightly too then.

(In reply to reviler853 from comment #28)

In 140.0b9 I don't see the bug anymore.

IIUC this has been mitigated by backout of bug 1966443. Do we still need this bug and if so, can we lower its severity? After all we are not shipping this anymore.

Flags: needinfo?(davidp99)

No, we don't need this anymore -- the original bug 1966443 is sufficient. I'm almost done studying this across all platforms and we have a lot of inconsistencies. Also, it occurred to me that drag-and-drop has the exact same cases... and it just adds more inconsistencies. I'm nearly done normalizing a solution for each platform.

Technical details: Because of the way things are implemented, we have five distinct cases per platform to consider.

  1. Copying from Fx to clipboard
  2. Pasting from clipboard to Fx
  3. Dragging from Fx to another app
  4. Dragging from another app to Fx
  5. Dragging from Fx to Fx

There is some overlap in the solutions but there is also always at least one platform that is an outlier. For example, (AFAICT) only Windows and GTK require null-termination for text contents (but for ease I think we should be consistent). Dragging from Fx to Fx is special because it (at least on some platforms) skips the system DND mechanism and its objects and just uses DataTransfer objects for the payload. And on Windows, we have to use an IDataObject (nsDataObj) to represent the payload.

We need to efficiently sanitize text data that we copy/drag out of Fx, to sanitize data that we bring in via paste or drop, and to handle the special Fx -> Fx DND case. This would also be consistent with other browsers I've tested.

Status: NEW → RESOLVED
Closed: 2 months ago
Flags: needinfo?(davidp99)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: