1885400 - Firefox 124 & later mangle drag&dropped URLs

Status: RESOLVED FIXED

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

Description

[kevink9876543]

Environment:

• Firefox 124.0rc1, or Firefox 125.0a1 official Nightly built from https://hg.mozilla.org/mozilla-central/rev/2333872b0f5028fa1f0e9236440fe58df07a0235
• Xubuntu 22.04
• new Firefox profile

To reproduce:

Drag&drop a link from an email in Evolution (Evolution installed as flatpak) onto Firefox, either in the browser content area or on the tab bar.

Expected results:

Firefox should load the link URL in the same tab (if dropped in the content area) or in a new tab (if dropped in the end of the tab bar)

Actual results:

In most cases:
If the link is dropped in the content area, nothing happens. If dropped in the end of the tab bar, Firefox opens a new tab to search for a sequence of non-ASCII characters that according to Character Map are mostly, but not entirely, CJK characters.

With some URLs, Firefox will instead try to load a completely unrelated IDN instead of the dragged URL. For example https://github.com/mozilla/pdf.js will transform into http://xn--4dmw12honcj4ap0a74lr7ds7bl9bc2jhmc6va99zk1ay74bwpx/.

Last working nightly built from: https://hg.mozilla.org/mozilla-central/rev/5f1d087788bb55c6786e4f0fb0126feb4a556a8b
First broken nightly built from: https://hg.mozilla.org/mozilla-central/rev/dbe553dd13b79a3c4821f203f3adca31fe71cc56

Comment 1

[kevink9876543]

Looking more closely at that regression range, tried building Firefox 124.0 release with applying hg backout --tool ':merge-other' bdabd37473ed5839557b90557ee6ca684a0d4500, and so far that seems to have restored the expected behavior. So this is regression from Bug 1786251 ?

Comment 2

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

Set release status flags based on info from the regressing bug 1786251

:jhorak, since you are the author of the regressor, bug 1786251, could you take a look?

For more information, please visit BugBot documentation.

Comment 3

[Jan Horak [:jhorak]]

Sure, I'll look at it.

Comment 4

[Jan Horak [:jhorak]]

Filled as upstream issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/6563 But I guess we'll fix/workaround this on our side too.

Comment 5

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

The bug is marked as tracked for firefox124 (release), tracked for firefox125 (beta) and tracked for firefox126 (nightly). However, the bug still has low priority.

:gcp, could you please increase the priority 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

[Jan Horak [:jhorak]]

Attachment: Bug 1885400 Don't use filetransfer portal for the remote content; r=stransky

The targets vnd.portal.filetransfer and vnd.portal.files usually contains the
numeric value data associated with the file transfer portal. In case
the dragged data is non-local file - like https link, the vnd.portal.files
target could also be send by the drag source application and it contains https uri.
The gtk_selection_data_get_uris call fails and cause delay and wrong
data to be received. This needs to be fixed by upstream, meanwhile introducing this
workaround to mitigate regression.

See: https://gitlab.gnome.org/GNOME/gtk/-/issues/6563

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d428c9e69fd5
Don't use filetransfer portal for the remote content; r=stransky

Comment 8

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/d428c9e69fd5

Comment 9

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

The patch landed in nightly and beta is affected.
:jhorak, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox125 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[kevink9876543]

Thanks for your work on this!

Unfortunately I'm still seeing the issue in Firefox Nightly (126.0a1 (2024-04-03) built from https://hg.mozilla.org/mozilla-central/rev/cfb42711da4589f5ede0032644a6d577d66aa468 ), as well as in a self build of Firefox 124.0.2 with https://hg.mozilla.org/mozilla-central/rev/d428c9e69fd5 applied via hg graft.

Is this fix included in the Firefox Nightly I tested? When grafting this patch onto Firefox 124.0.2, did I miss something else that also needed to be backported for it to work?

Comment 11

[kevink9876543]

(In reply to kevink9876543 from comment #10)

Is this fix included in the Firefox Nightly I tested?

Per bug 1888202 comment 7 it is. Reopening on that basis

Comment 12

[kevink9876543]

Now this is interesting: converting the IDN in the description to Unicode, and then encoding the result as UTF-16 gives this -

Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import encodings.idna as idna
>>> b=idna.ToUnicode('xn--4dmw12honcj4ap0a74lr7ds7bl9bc2jhmc6va99zk1ay74bwpx')
>>> b
'瑨灴㩳工楧桴扵挮浯洯穯汩慬瀯晤樮'
>>> import codecs
>>> codecs.encode(b, 'utf_16')
b'\xff\xfehttps:\xe5]github.com/mozilla/pdf.j'

Does this offer any insight into this issue?

Comment 13

[Jan Horak [:jhorak]]

Sorry I've focused on the first part of the bug, the unicode problem should be solved by: https://bugzilla.mozilla.org/show_bug.cgi?id=1888202

Comment 14

[kevink9876543]

Seems this bug is a different Unicode problem? Tried a self build of mozilla-central rev 93d08e6b3d615ead541eee15f876af2c74e90d53 with the patch from bug 1888202 applied on top, and I can still reproduce this issue.

(I am not able to reproduce bug 1888202 on this self build, following the steps in bug 1888202 comment 3. Tested both the sample text in that comment, and the sample text in that bug's description.

On Firefox 124.0.2 release I do see bug 1888202, so can confirm the patch for bug 1888202 is working as intended on my system.)

Comment 15

[Donal Meehan [:dmeehan]]

:jhorak next week is the final week of beta for Fx126.
Was wondering if you plan on follow-ups here, or should we expect something in time for a later release?

Comment 16

[Jan Horak [:jhorak]]

This - the mangled unicode data should be fixed by: https://bugzilla.mozilla.org/show_bug.cgi?id=1888202 and uplifted to release.
Do you want me to create beta uplift too, or is it covered by the release uplift or is it enough?

Comment 17

[Donal Meehan [:dmeehan]]

(In reply to Jan Horak [:jhorak] from comment #16)

This - the mangled unicode data should be fixed by: https://bugzilla.mozilla.org/show_bug.cgi?id=1888202 and uplifted to release.
Do you want me to create beta uplift too, or is it covered by the release uplift or is it enough?

Thanks, Bug 1888202 is already in Fx126 Beta.

Are you planning any other changes here in Bug 1885400?

Comment 18

[Jan Horak [:jhorak]]

Let's ask reporter if he still see the other issue - evolution drag and drop fails.

Comment 19

[kevink9876543]

Hi, yes I am still seeing this issue in Firefox 126.0b5.

(And can confirm that Bug 1888202 is still fixed in this version.)

Comment 20

[Martin Stránský [:stransky] (ni? me)]

Will address it at Bug 1881229.

Comment 21

[kevink9876543]

Can confirm this seems fixed in Firefox Nightly 128.0a1 (2024-05-14) built from https://hg.mozilla.org/mozilla-central/rev/b2c1906d3f6e950d783cb681442333a5cea96d8f . Thanks :stransky! :D

Comment 22

[Martin Stránský [:stransky] (ni? me)]

Thanks for testing.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

If we wanted to fix this in 127 still, is there a relatively backportable fix from that stack of changes we could uplift? I'm assuming we don't need all of them...

Comment 24

[Martin Stránský [:stransky] (ni? me)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #23)

If we wanted to fix this in 127 still, is there a relatively backportable fix from that stack of changes we could uplift? I'm assuming we don't need all of them...

The fix is quite big and hard to backport.