The default bug view has changed. See this FAQ.

Dragging from Downloads window and dropping in Finder creates weird shortcut

RESOLVED FIXED in mozilla25

Status

()

Core
Widget: Cocoa
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: djst, Assigned: marco)

Tracking

Trunk
mozilla25
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Bug 462172 appears to be cross-platform, but I noticed today that it doesn't work on the Mac. This is tested on Firefox 19 running on OS X 10.8.2. 

When dropping a file from the Download window on Firefox onto e.g. the desktop, a strange shortcut is created instead of actually moving/copying the file there. This is different from how it works on Windows.

Comment 1

4 years ago
A weird shortcut indeed.  It's called "Users:.fileloc" in terminal or "Users/.fileloc" in finder, and it has an Opera icon.  But double-clicking it opens the PDF I downloaded in Preview.
Duplicate of this bug: 875381
Version: unspecified → Trunk
Is bug 544932 the problem?
Created attachment 784254 [details] [diff] [review]
Patch
Attachment #784254 - Flags: feedback?(khuey)
Component: Downloads Panel → Widget: Cocoa
Product: Firefox → Core
Comment on attachment 784254 [details] [diff] [review]
Patch

Review of attachment 784254 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/cocoa/nsClipboard.mm
@@ +483,5 @@
> +      if (!file) {
> +        nsCOMPtr<nsISupportsInterfacePointer> ptr(do_QueryInterface(genericFile));
> +        if (ptr) {
> +          ptr->GetData(getter_AddRefs(file));
> +        }

I'm kind of surprised this compiles.  GetData returns an nsISupports*, not an nsIFile*.  I would expect you to need to pass in an getter_AddRefs<nsISupports> here and QI to nsIFile afterwards.
Attachment #784254 - Flags: feedback?(khuey)
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5)
> I'm kind of surprised this compiles.  GetData returns an nsISupports*, not
> an nsIFile*.  I would expect you to need to pass in an
> getter_AddRefs<nsISupports> here and QI to nsIFile afterwards.

On Windows we're doing the same: http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsDataObj.cpp#1357
Blocks: 462172
Created attachment 784461 [details] [diff] [review]
Patch v2
Attachment #784254 - Attachment is obsolete: true
Attachment #784461 - Flags: feedback?(khuey)
(In reply to Marco Castelluccio [:marco] from comment #6)
> (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5)
> > I'm kind of surprised this compiles.  GetData returns an nsISupports*, not
> > an nsIFile*.  I would expect you to need to pass in an
> > getter_AddRefs<nsISupports> here and QI to nsIFile afterwards.
> 
> On Windows we're doing the same:
> http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsDataObj.
> cpp#1357

Yeah turns out this is a bug in nsCOMPtr.  This shouldn't be allowed.
Comment on attachment 784461 [details] [diff] [review]
Patch v2

Review of attachment 784461 [details] [diff] [review]:
-----------------------------------------------------------------

Looks reasonable.
Attachment #784461 - Flags: feedback?(khuey) → feedback+
Attachment #784461 - Flags: review?(bgirard)

Updated

4 years ago
Attachment #784461 - Flags: review?(bgirard) → review+
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/d0f70faea778
Assignee: nobody → mcastelluccio
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/d0f70faea778
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.