drag and drop text unable to render unicode / UTF-8 characters
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: mgc.lude, Assigned: jhorak)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(3 files)
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.
Comment 1•11 months ago
|
||
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.
![]() |
||
Comment 3•11 months ago
|
||
[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
- Open gedit and type
この記事は、Mozilla Firefox のキーボードショートカットの一覧表です。
and select all - Open
data:text/html,<textarea>
in Firefox - Drag text from gedit to the textarea
![]() |
||
Updated•11 months ago
|
Updated•11 months ago
|
Comment 4•11 months ago
|
||
:jhorak not sure if this is similar to bug 1885400? could you take a look?
Updated•11 months ago
|
Comment 5•11 months ago
|
||
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.
Comment 6•11 months ago
|
||
Bot, you are wrong...
I guess this counts as a passed Turing test, because the bot was right.
Comment 7•11 months ago
|
||
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
Comment 8•11 months ago
|
||
That bug was reopened so it may still be the same underlying issue.
Updated•11 months ago
|
Updated•11 months ago
|
Assignee | ||
Comment 9•11 months ago
|
||
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.
Updated•11 months ago
|
Updated•11 months ago
|
Comment 10•11 months ago
|
||
Assignee | ||
Comment 11•11 months ago
|
||
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
Updated•11 months ago
|
Comment 12•11 months ago
|
||
bugherder |
Updated•11 months ago
|
Updated•11 months ago
|
Comment 13•11 months ago
|
||
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
Assignee | ||
Updated•11 months ago
|
Comment 14•10 months ago
|
||
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?
Comment 15•10 months ago
|
||
I can confirm that the STR from comment 3 work for me now with a current Nightly.
Updated•10 months ago
|
Updated•10 months ago
|
Comment 16•10 months ago
|
||
uplift |
Comment 17•10 months ago
|
||
Added to the 125.0.3 relnotes.
Fixed corruption of text containing unicode characters when being dragged on Linux systems
Updated•10 months ago
|
Comment 18•10 months ago
|
||
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.
Description
•