Closed Bug 1823751 Opened 1 year ago Closed 1 year ago

Cannot drag-and-drop from downloads to desktop

Categories

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

Firefox 111
Unspecified
macOS
defect

Tracking

()

VERIFIED FIXED
113 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox111 --- wontfix
firefox112 --- verified
firefox113 --- verified

People

(Reporter: jscher2000, Assigned: bradwerth)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Numerous Mac OS users reported this problem on SUMO starting March 16, 2023. As a Windows person, I cannot replicate the problem.

Suggestions for SUMO contributors about what to suggest or what to ask can be added in the following thread as well:

https://support.mozilla.org/en-US/forums/contributors/716226#post-85164

:evilpie, since you are the author of the regressor, bug 1798548, could you take a look?

For more information, please visit auto_nag documentation.

Flags: needinfo?(evilpies)

I am not a mac developer what I can say is that I am very surprised that this even worked before, because from what I remember this was giving me some kind of error: https://hg.mozilla.org/integration/autoland/rev/330c5c6b4f5bd2ba3818e6859d1757023a5ac29a#l3.12

Brad do you want to take a look?

Flags: needinfo?(evilpies) → needinfo?(bwerth)

I'll look at this soon. Do you recall why it was necessary to change the pasteboard type from NSString to NSData? Did that make some test pass?

I had to change this, because I got an exception in the new test that I was adding: https://phabricator.services.mozilla.com/D160944#5424063.

Well, I can replicate and now that I know which test was the inspiring case for the change, I'm happy to take the Bug and try to keep the test passing while restoring the interactive behavior.

Assignee: nobody → bwerth
Flags: needinfo?(bwerth)

Replicating this in a local build generates this console output:

Mozilla has caught an Obj-C exception [NSInvalidArgumentException: Calling -setString:forType: on NSPasteboard or NSPasteboardItem with object of type NSConcreteMutableData instead of NSString.]

which seems to indicate that the pasteboard will only accept NSString for the "public.file-url" key.

This change makes PasteboardDictFromTransferable use NSString to store the
file url in the NSDictionary, and then when converting to the native
pasteboard, check whether we should use the setString method for strings,
or the setData method for all other values. This complies with the macOS
requirement that NSString content is used for the kUTTypeFileURL key.

Thank you for fixing this Brad. I hope we can add this to the QA drag&drop manual tests so that we don't regress it again on any platform.

Duplicate of this bug: 1824201
Component: Downloads Panel → Widget: Cocoa
Product: Firefox → Core
Severity: -- → S3
Priority: -- → P3
Pushed by bwerth@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/baa3ac5e605e
Make macOS pasteboard use NSString for urls, and don't convert to NSData. r=mac-reviewers,spohl
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch

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

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(bwerth)

:bradwerth could you also add release uplift approval when adding beta uplift approval?
We may not have another 111 dot release, but could consider taking this if we do.

Comment on attachment 9324558 [details]
Bug 1823751: Make macOS pasteboard use NSString for urls, and don't convert to NSData.

Beta/Release Uplift Approval Request

  • User impact if declined: macOS users can't drag-and-drop file URLs (bookmarks, downloads) from Firefox to desktop or to other applications.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Download any file, open the Downloads panel and drag the icon of the downloaded file to the desktop. Expected results: icon appears on desktop.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This partially reverts a recent change to return to longstanding pasteboard behavior which has worked correctly.
  • String changes made/needed:
  • Is Android affected?: No
Flags: needinfo?(bwerth)
Attachment #9324558 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9324558 [details]
Bug 1823751: Make macOS pasteboard use NSString for urls, and don't convert to NSData.

Release uplift request same as comment 15.

Attachment #9324558 - Flags: approval-mozilla-release?

Comment on attachment 9324558 [details]
Bug 1823751: Make macOS pasteboard use NSString for urls, and don't convert to NSData.

Approved for 112.0b8

Attachment #9324558 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]
Duplicate of this bug: 1824966

Reproduced the initial issue using a Firefox 111.0.1 on a macOS 13, and also verified that using the latest Firefox Beta build 112.0b8 and latest Nightly 113.0a1 from today I now can drag drop downloaded files to the desktop without issues.
I did noticed that the icons for the dragged files are cropped or very tiny while dragged and not dropped. Once they are dropped the correct icon is displayed for the file, will log an additional bug asap. Will leave this bug as RESOLVED for now and not move it to VERIFIED since Firefox 111 is still affected and maybe will be uplifted there as well.

Comment on attachment 9324558 [details]
Bug 1823751: Make macOS pasteboard use NSString for urls, and don't convert to NSData.

There is no 111 dot release planned before 112 go-live.
This will ride the trains with 112.

Attachment #9324558 - Flags: approval-mozilla-release? → approval-mozilla-release-

(In reply to Bogdan Maris, Desktop QA from comment #20)

I did noticed that the icons for the dragged files are cropped or very tiny while dragged and not dropped. Once they are dropped the correct icon is displayed for the file, will log an additional bug asap.

Logged Bug 1825782 as an enhancement for this.

Also closing this bug as VERIFIED since this will not land in Fx 111.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: