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

Steps to reproduce:

I need to drag and drop text from a source (pdf, simple text file, etc) into a CMS box on Firefox. On Firefox 123 this worked normally and certain characters, like à á é è ç « » ô õ would be recognised and showed up fine (I work with Portuguese and French languages).
This happens every time a text is dragged and dropped, it doesn't matter the source or destination of the text (CMS, Form, other).

On Firefox 124 this doesn't work anymore and these characters show as:
\u00e0 \u00e1 \u00e9 \u00e8 \u00e7 \u00ab \u00bb \u00f4 \u00f5

If I copy and paste the same text, this doesn't happen. But I need the drag and drop function to work as it did, as it allows for a faster workflow.
Many other people I know have noticed the same issue.

I'm on Firefox 124.0.1 64 bit on Gnu-Linux (Ubuntu 22.04). The issue happens on both Snap and Flatpack packages.

Actual results:

This is a sample text:

O novo líder do Parlamento avisou, no entanto, que as comissões parlamentares de inquérito "não podem ser o cartão de visita desta casa", alertando contra os riscos da "espetacularização" mediática da atividade política.

This is the result after drag and drop:

O novo l\u00edder do Parlamento avisou, no entanto, que as comiss\u00f5es parlamentares de inqu\u00e9rito "n\u00e3o podem ser o cart\u00e3o de visita desta casa", alertando contra os riscos da "espetaculariza\u00e7\u00e3o" medi\u00e1tica da atividade pol\u00edtica.

Expected results:

The text should show the correct characters, as in the source sample.

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.

Bot, you are wrong...

[Tracking Requested - why for this release]: Broken drag and drop UTF-8 characters

I can reproduce this on Nightly126.0a1 Ubuntu22.04.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2b4e9ee6225f1183da45d24404e72f48e3803f08&tochange=bdabd37473ed5839557b90557ee6ca684a0d4500

STR

1. Open gedit and type この記事は、Mozilla Firefox のキーボードショートカットの一覧表です。 and select all
2. Open data:text/html,<textarea> in Firefox
3. Drag text from gedit to the textarea

:jhorak not sure if this is similar to bug 1885400? could you take a look?

The bug is marked as tracked for firefox124 (release), tracked for firefox125 (beta) and tracked for firefox126 (nightly). We have limited time to fix this, the soft freeze is in 8 days. However, the bug still isn't assigned.

:gcp, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Bot, you are wrong...

I guess this counts as a passed Turing test, because the bot was right.

AFAICT, bug 1885400 didn't help here. Following the STR in comment 3, I see the same results with today's Nightly build as I do with 124.0.2 on Ubuntu 24.04.

\u3053\u306e\u8a18\u4e8b\u306f\u3001Mozilla Firefox \u306e\u30ad\u30fc\u30dc\u30fc\u30c9\u30b7\u30e7\u30fc\u30c8\u30ab\u30c3\u30c8\u306e\u4e00\u89a7\u8868\u3067\u3059\u3002

That bug was reopened so it may still be the same underlying issue.

Since we clear the mTargetDragData in the GetTargetDragData the calling it for the
application/vnd.portal.files and later just to find out if they are present clears already
obtained mTargetDragData which could contain actual text/plain;utf8 and not file uri data
which should be later used.

Since we clear the mTargetDragData in the GetTargetDragData the calling it for the
application/vnd.portal.files and later just to find out if they are present clears already
obtained mTargetDragData which could contain actual text/plain;utf8 and not file uri data
which should be later used.

Original Revision: https://phabricator.services.mozilla.com/D206760

https://hg.mozilla.org/mozilla-central/rev/4cb13456c91f

release Uplift Approval Request

• User impact if declined: The dragged text with unicode characters will be mangled under Linux
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: Drag text from the third party app into the firefox uri bar
• Risk associated with taking this patch: none
• Explanation of risk level: This won't affect negatively user experience.
• String changes made/needed: none
• Is Android affected?: no

Hi Miguel, the fix for this bug should be available in Nightly and Beta builds. Are you able to confirm that things are working better for you now?

I can confirm that the STR from comment 3 work for me now with a current Nightly.

Added to the 125.0.3 relnotes.

Fixed corruption of text containing unicode characters when being dragged on Linux systems

Reproduced the issue using and old Nightly build from 2024-03-26 using the steps from comment 3. I also verified that this is fixed using latest builds 126.0b6 Beta and 125.0.3 RC on Ubuntu 22.04. Since the reporter of the bug has not responded yet I'll go ahead and close this as verified. Please let us know if this also works for you Miguel when you get the chance.