44260 - Mac: Drag linked images to desktop -> poor text clipping

Status: RESOLVED WORKSFORME

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

Description

[Eli Goldberg]

* TITLE/SUMMARY
Drag linked images to desktop ---> sub-optimal text clipping

* STEPS TO REPRODUCE
0) Launch Seamonkey
1) Drag an image to your desktop. 
(e.g. <http://www.mozilla.org/quality/browser/front-end/testcases/drag-drop/drag-
url-browser-desktop/drag-url-browser-desktop-d.html>)

* RESULT
 - What happened

A text clipping results, containing the image's ALT text, and with a title of 
[ALT text] + "clipping".

 - What was expected 

Pinkerton suggests that if we're not going to actually support dragging images to 
the desktop, we should at least provide the source URL to the image in the 
clipping's content.

[Personally, I don't think either alternative is particularly useful --- if you 
drag something to a window, you want what you're dragging. More meta-information 
might be useful, for example, if you assume that it was dragged and want to go 
back and manually save the image?]

* REGRESSION

 - Occurs On
        Mac OS Seamonkey (6.29.00 AM optimized build)		

 - Doesn't Occur On
        Win32 Seamonkey (6.29.00 AM optimized build [NT 4, Service Pack 5]) --- 
dragging to desktop is nonfunctional
        Linux Seamonkey --- no usable build provided in past 3 days := no testing 
on that platform.


* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM 
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (266 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

[Eli Goldberg]

QA Assigning to self.

Comment 2

[Chris McAfee]

m19, needs owner

Comment 3

[Andrew Thompson]

Please see 
http://bugzilla.mozilla.org/show_bug.cgi?id=45823

which may be a duplicate, except that the symptoms and the situation are somewhat 
different. This bug speaks of linked images creating a text clipping with the alt 
text in it, an 45823 talks about *unlinked* images creating a text clipping with 
the *filename* in it.

Also the situation described in this bug is working for me in 2000071710 on Mac 
OS - dragging a linked image to the desktop is creating an image on the desktop, 
not a text clipping. Its just unlinked images that are busted on Mac OS now.

Can anyone confirm this?

Comment 4

[Matthew T (active 1999-2002)]

Build: 2000090820, MacOS 9.0

Drag a linked image to the Finder.

What I got:
* Internet shortcut
* name of shortcut = truncated (with ellipsis:-) URL of link, excluding protocol
* Comments of shortcut = nothing.

What I expected:
* Internet shortcut (if I really want the image, I can choose `View Image' first)
* name of shortcut = replacement text for image (ALT or TITLE, as calculated by
  the getAltSomethingSomething function which Hixie worked on a while back), or
  failing that, the protocol-less ellipsis-truncated URL of the link
* Comments field of shortcut = URL of image (ellipsis-truncated if necessary).

Taking QA, since Eli has gone.

Comment 5

[Kathleen :Brade]

This bug was noted by Jason Beach at http://www.macintouch.com/netscape6.html:

Drag and drop implementation is lacking across the interface. Dragging an image
out of a window drops a text clipping of the link.

Comment 6

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 7

[Chris McAfee]

pchen

Comment 8

[Peter Trudelle]

marking mozilla0.9.9

Comment 9

[Matthew T (active 1999-2002)]

Worksforme, build 2001111508, Mac OS 9.1. Non-link images not creating an image
file is bug 45823.