Closed Bug 1885400 Opened 3 months ago Closed 1 month ago

Firefox 124 & later mangle drag&dropped URLs

Categories

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

Firefox 124
Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
128 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox124 + wontfix
firefox125 + wontfix
firefox126 + wontfix
firefox127 + wontfix
firefox128 + fixed

People

(Reporter: kevink9876543, Assigned: jhorak)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Environment:

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

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 ?

Keywords: regression
Regressed by: 1786251

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.

Flags: needinfo?(stransky)
Blocks: linuxdad
Component: Untriaged → Widget: Gtk
Flags: needinfo?(stransky)
Priority: -- → P3
Product: Firefox → Core
Flags: needinfo?(stransky)

Sure, I'll look at it.

Flags: needinfo?(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.

Assignee: nobody → jhorak

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.

Flags: needinfo?(gpascutto)
Flags: needinfo?(gpascutto)

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

Flags: needinfo?(stransky)
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/d428c9e69fd5
Don't use filetransfer portal for the remote content; r=stransky
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 126 Branch

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.

Flags: needinfo?(jhorak)
See Also: → 1888202

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?

(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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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?

Target Milestone: 126 Branch → ---

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

Flags: needinfo?(jhorak)

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.)

Flags: needinfo?(stransky)

: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?

Flags: needinfo?(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?

Flags: needinfo?(jhorak) → needinfo?(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?

Flags: needinfo?(dmeehan) → needinfo?(jhorak)

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

Flags: needinfo?(kevink9876543)
Flags: needinfo?(jhorak)

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

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

Flags: needinfo?(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

Depends on: 1881229
See Also: 1888202

Thanks for testing.

Status: REOPENED → RESOLVED
Closed: 2 months ago1 month ago
Flags: needinfo?(stransky)
Resolution: --- → FIXED
Target Milestone: --- → 128 Branch

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...

Flags: needinfo?(stransky)

(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.

Flags: needinfo?(stransky)
QA Whiteboard: [qa-128b-p2]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: