1914742 - [KDE] Gmail - File drag and drop broke on KDE/Linux , 126.0.2->129.0.2

Status: RESOLVED FIXED

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

Description

[dfeari]

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

Steps to reproduce:

1. On KDE, open Firefox 126.0.2
2. Go to GMail
3. Compose a new e-mail
4. Drag a file from the KDE desktop or Dolphin to the e-mail. It will upload & attach the file, as expected (and as in all prior versions of Firefox)
5. Update to Firefox 129.0.2
6. Repeat the same. It no longer attaches the file - instead, it just inserts the text of the path of the file (i.e. "file:///home/username/Desktop/somefile.jpg)

The same is true of other sites - i.e. can no longer drag files into Facebook chat conversations, etc.

Actual results:

Described in steps

Expected results:

Described in steps

Comment 1

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

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 2

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

Can you use mozregression tool to find broken commit?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Use_Mozregression_tool
Thanks!

Comment 3

[dfeari]

5:56.50 INFO: Narrowed integration regression window from [aba3d5bd, f061d37c] (3 builds) to [068001f3, f061d37c] (2 builds) (~1 steps left)
5:56.50 INFO: No more integration revisions, bisection finished.
5:56.50 INFO: Last good revision: 068001f3181654a5663191fc437ab74f19ab3f7f
5:56.50 INFO: First bad revision: f061d37ca7aea8d05d976908e376e649257f2151
5:56.50 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=068001f3181654a5663191fc437ab74f19ab3f7f&tochange=f061d37ca7aea8d05d976908e376e649257f2151

Comment 4

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

Looks like there are lot of D&D changes in that range.
Please attach your about:support page.
Thanks.

Comment 5

[dfeari]

Quite a bit on that page - are there any particular sections you're interested in? I prefer to review any logs/content like that for privacy reasons, would be quicker to send just the relevant sections if possible.

Comment 6

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

Okay, please try to create a screencast of the issue:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Create_screenshot/screencast_for_a_bug_report
Thanks.

Comment 7

[dfeari]

Attachment: Peek 2024-09-02 20-58.gif

Attached. First I show the broken behavior in the current version of Firefox; then I show the correct behavior in Brave (which reflects how Firefox worked before the broken update).

Comment 8

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

It works for me in Gnome/Wayland/Firefox 130.0. May be KDE specific.

Comment 9

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

Please run Firefox on terminal with MOZ_LOG="WidgetDrag:5" env variable, reproduce the issue and attach the log here. Run for instance:

MOZ_LOG="WidgetDrag:5" firefox > log.txt 2>&1

and attach log.txt file.
Thanks.

Comment 10

[dfeari]

Attachment: log.txt

I'm also using x11, not Wayland.

Attached

Comment 11

[dfeari]

Still broken on 130.0.1

Comment 12

[varishtsg]

Still facing this on firefox 133.0. Using Kubuntu 22.04 with X11 desktop backend.

Comment 14

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

May be dupe of Bug 1917854.

Comment 15

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

This may be the bug:

[Parent 154475: Main Thread]: D/WidgetDrag nsWindow::OnDragDataReceived
[Parent 154475: Main Thread]: D/WidgetDrag [D 2] nsDragService::TargetDataReceived(7fc5d06a69e0) MIME application/vnd.portal.filetransfer mWaitingForDragDataRequests 0
[Parent 154475: Main Thread]: D/WidgetDrag [D 2] TargetDataReceived(): plain data, MIME application/vnd.portal.filetransfer len = 19
[Parent 154475: Main Thread]: D/WidgetDrag [D 1] application/vnd.portal.filetransfer received
[Parent 154475: Main Thread]: D/WidgetDrag DragData::Export() MIME application/vnd.portal.filetransfer index 0
[Parent 154475, Main Thread] WARNING: g_strv_length: assertion 'str_array != NULL' failed: 'glib warning', file /build/firefox-NUtzHF/firefox-129.0.2+build1/toolkit/xre/nsSigHandlers.cpp:187

(firefox:154475): GLib-CRITICAL **: 16:12:46.657: g_strv_length: assertion 'str_array != NULL' failed

Comment 16

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

Can you please re-test with latest nightly?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_Nightly_binaries
I can't reproduce it with Fedora 41 / KDE / X11.
Thanks.

Comment 17

[dfeari]

Still broken in 135.0a1 (2024-12-04)

Comment 18

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

Thanks for testing. I'd need fresh logs for it.

Please run Firefox on terminal with MOZ_LOG="WidgetDrag:5" env variable, reproduce the issue and attach the log here. Run for instance:
MOZ_LOG="WidgetDrag:5" firefox > log.txt 2>&1
and attach log.txt file.

Thanks.

Comment 19

[dfeari]

Attachment: drag-log.txt

Comment 20

[dfeari]

Attached

Comment 21

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

Thanks. Please attach about:support page.

I suspect Bug 1908196 may fix this one, let's re-test when it lands.

Comment 22

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

According to the log you use old Gtk3 version where gtk_targets_include_uri() doesn't include portal MIME types.

Comment 23

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

Attachment: Bug 1914742 [Linux] Don't use gtk_targets_include_uri() to get URI MIME types as it depends on Gtk3 version r?emilio

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3cfce0e75164
[Linux] Don't use gtk_targets_include_uri() to get URI MIME types as it depends on Gtk3 version r=emilio

Comment 25

[dfeari]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #21)

Thanks. Please attach about:support page.

I suspect Bug 1908196 may fix this one, let's re-test when it lands.

Easier to just re-test when it lands, lmk when ready + I will

Comment 26

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/3cfce0e75164

Comment 27

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

Landed so please test.
Thanks.

Comment 28

[dfeari]

confirmed, fixed at last.

Any idea how long these nightlies end up taking to make it into production?

Comment 29

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

I'll do backport for Beta.

Comment 30

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

Attachment: Bug 1914742 [Linux] Don't use gtk_targets_include_uri() to check URI types for 134.0 r?emilio

Comment 31

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

Comment on attachment 9442385 [details]
Bug 1914742 [Linux] Don't use gtk_targets_include_uri() to check URI types for 134.0 r?emilio

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Firefox fails to D&D files or file link if running on old Gtk3 version where gtk_targets_include_uri() doesn't support portal filetypes.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We only replace Gtk3 function with our correct check.
• String changes made/needed:
• Is Android affected?: Yes

Comment 32

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/d74fea53a009

Comment 33

[Ryan VanderMeulen [:RyanVM]]

Do we want this on ESR128 also?

Comment 34

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

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

Do we want this on ESR128 also?

Yes, I think so.

Comment 35

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

Comment on attachment 9442385 [details]
Bug 1914742 [Linux] Don't use gtk_targets_include_uri() to check URI types for 134.0 r?emilio

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Firefox fails to D&D files or file link if running on old Gtk3 version where gtk_targets_include_uri() doesn't support portal filetypes.
• User impact if declined:
• Fix Landed on Version:
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We only replace Gtk3 function with our correct check.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9442385 [details]
Bug 1914742 [Linux] Don't use gtk_targets_include_uri() to check URI types for 134.0 r?emilio

Approved for 128.6esr.

Comment 37

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/27c5e4229000