Open Bug 401380 Opened 17 years ago Updated 2 years ago

Images dragged to desktop don't land where you drop them, move folders

Categories

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

x86
macOS
defect

Tracking

()

People

(Reporter: froodian, Unassigned)

References

Details

(Keywords: regression, Whiteboard: tpi:+)

Post promised-file dragging regression?

1. Drag an image to the desktop
2. Drop it

The image lands somewhere other than where you dropped it.  Even better:

1. Drag an image
2. Drop it on a folder on the desktop

The folder now relocates iteslf to somewhere random on the desktop.
Flags: blocking1.9?
Keywords: regression
Stan mentioned the file-position issue in bug 358093 comment 3 and then never again, so I don't know what happened, but the folder-moving part is new (and very, very scary to see in action, especially if you can't see the spot where the folder ends up).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yeah, I never figured out how to make the drag go to a non-default position, was going to file a bug on that. The folder move is new to me too, sounds like maybe this should be a blocker candidate.
Safari (at least 1.x and 2.x) get this right; is there a chance the WebKit source might have some clues?
I didn't see anything helpful in a cursory scan of webkit bits several months ago, but probably worth taking another look.
Flags: blocking1.9? → blocking1.9-
Josh, out of curiosity, is there a particular reason that you -ed this bug after Stan agreed that it should be a potential blocker?  If you guys had a conversation that's cool, but a clarifying comment might have helped.
I didn't talk to Stan about it. I looked into this stuff a while ago and the answer I got from Apple is yeah, the Finder is weird. Just let it do its thing. I see this behavior in other Apple apps too.
A couple of additional observations:

1. Dragging an image to the iTunes Artwork tab doesn't work either. It looks like it will work, as the cursor gets the green plus while hovering over the tab, but if you release the mouse button, the image isn't added. The Artwork tab is the last tab when you do a Get Info on a track.

2. Dragging text works fine. If you drop the text on the desktop, a text clipping is created where the cursor was when the mouse button was released. If you drop the text on the Lyrics tab in the iTunes Get Info window, the text is added to the lyrics.

3. Dragging images to the desktop, a folder, or iTunes works as expected in Firefox 2.x (image placed at cursor location, folder not moved, image added as artwork).
I can confirm that it works on my latest version of Firefox 2, but I'm quite sure that it worked that way since day 1 I've used it.

I think that looking at what's changed it a bit tricky uh? :D
Same here with regards to dropping into a folder. This only started happening when I upgraded to 3.0 after using an up-to-date version of 2.x.
Summary: Images dragged to desktop don't land where you drop them → Images dragged to desktop don't land where you drop them, move folders
Issue still present in release 3.0.1.
(In reply to comment #16)
> Issue still present in release 3.0.1.

This bug being marked as "NEW" and not as "RESOLVED" means we know it's still unfixed. There's no need to comment about it.

See also: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
FWIW, I know this exact problem occurred in a previous build of Firefox--I'm not sure, but I think it was in 2.0.  The bug was eventually resolved in one of the subsequent 2.x builds, and it didn't resurface until 3.0.  Maybe there's some hint there in how to fix it?
I had never seen this bug until i updated to Firefox 3.0 though i've used it off and on since 1.5 and this is driving me nuts. On VERY rare occasions i've had an image dragged from a finder window to the desktop do this.  Only 3 times in memory and i can't reproduce the behavior there.

I'm now using Firefox 3.0.4 and OS X 10.5.6.  No change.
I also can't drag an image directly into Photoshop - it says it doesn't recognize the file type. I have to drag to the desktop and then to Photoshop. Safari does this just fine.
(In reply to comment #22)
> I also can't drag an image directly into Photoshop - it says it doesn't
> recognize the file type. I have to drag to the desktop and then to Photoshop.
> Safari does this just fine.

That's not this bug.  It may be bug 433093, or it may be a separate bug, depending on the drag flavors Photoshop wants and so forth.
One odd behavior.  I was initially having problems with a folder on my desktop being moved to the upper left corner of the desktop when I dropped something into it, and of files dropped directly on the desktop ending up in the upper-left corner no matter where on the desktop they were dropped.

At some point I experimented with making a new drop folder, copying the contents over, and deleting the folder I had been using.  I'm not sure if it was at the same time I replaced the folder or not, but now everything I drop goes to the RIGHT side of the screen in the highest vacant position (rather than to the upper left).  While this is not a particularly useful behavior, it also reflects where the folder usually lives, so the problem is no longer inconveniencing me.
Assignee: joshmoz → nobody
> I didn't talk to Stan about it. I looked into this stuff a while ago and the
> answer I got from Apple is yeah, the Finder is weird. Just let it do its thing.
> I see this behavior in other Apple apps too.

I've only seen it maybe 3 times in Finder and nowhere else but Firefox.  Now i've upgraded to Snow Leopard, with the rewritten Finder, and the bug is STILL around.
This is still the worst thing ever. It's  been driving me nuts for over a year, stopped once for about a week, and then came back. Please fix this.
Agreed.  Somebody please look into this.  It's survived Firefox 3.0 through 3.5.5 and from OS X Leopard 10.5.2 through Snow Leopard 10.6.2, including freshly created Firefox folders and system reinstalls and affects multiple systems!
One more bit of information: while this bug is definitely still present in Firefox 3.5.7, it does **not** affect aliases on the desktop. 

If you drop an image onto a folder icon on the desktop, the folder will relocate itself to the first available slot in the Finder's arrangement scheme (i.e. the first icon-sized opening on the desktop starting in the upper right corner and working down then left--standard Finder behavior).  This is always repeatable.

If, however, you create an alias of that same folder and drop an image onto the alias, the alias remains in place on the desktop.  The original folder still relocates as if you've dropped onto that folder, and the dropped file does end up in that folder, but the alias doesn't move.  

So...that's a workaround for this bug.  And hopefully it helps figure out what's going on...
I'm not seeing the shift of desktop folders into which images are dropped under FF 3.6, but images dropped directly to the desktop still get shifted.
(In reply to comment #30)
> I'm not seeing the shift of desktop folders into which images are dropped under
> FF 3.6, but images dropped directly to the desktop still get shifted.

Hmm...I'm definitely seeing it still present in 3.6 (Mac OS 10.4.11, PPC); the workaround I described above of dropping onto a folder's alias still works, but mine still moves the dropped file (or the folder it's dropped into) into the first available position on the desktop.
The alias folders still moved around for me, but one thing I did notice is if I make a new folder, it doesn't move. After a few months, suddenly the folder moves around again. Really odd. Then I just make a new one and toss the old one and it works correctly again.
still present in version 4... :(
Reproducible
1. Drag an image to the desktop
2. Drop it
Firefox does not place the image where the drop occurred, while Safari does drop it in designated place

Not Reproducible
1. Drag an image
2. Drop it on a folder on the desktop
Firefox placed the image in the selected folder where it was dropped (Safari too)

Version 	46.0.1
Build ID 	20160502172042
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Priority: -- → P4
Whiteboard: tpi:+
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 15 duplicates and 20 votes.
:spohl, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(spohl.mozilla.bugs)
You need to log in before you can comment on or make changes to this bug.