131036 - Dragging linked image to Finder/Explorer should make shortcut

Status: NEW

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

Description

[Terri Preston]

Steps to reproduce:

1. Go to URL
2. Drag the image of the space shuttle to the desktop


Expected results:
a link to the dragme.html page should be created on your desktop. 
Actual results: 
I get an error that the filename, directory name, or volume label syntax is 
incorrect

I see this on win xp build 2002031403 as well as branch build

Comment 1

[Pete Boyd]

reporter, are you still seeing this problem?

Comment 2

[Terri Preston]

*** Bug 148034 has been marked as a duplicate of this bug. ***

Comment 3

[Terri Preston]

Duplicate was written on Mac and I saw it on trunk build 2002052911 and linux
branch 20020528, changing OS to all

Comment 4

[Terri Preston]

qa contact -> pmac

Comment 5

[Simon Fraser [no longer active]]

Dup of bug 97413? Bugs for Mac also exist (bug 45823, bug 45824).

Comment 6

[Matthew T (active 1999-2002)]

Not a dup. This bug is about dragging an image which *is* a link (see the 
testcase). Bug 97413 is about dragging an image which is *not* a link.

Comment 7

[Simon Bünzli]

Attachment: prefer anchor over image

Since I've got no C++ environment, this patch hasn't been verified to run. A simple solution should however be about as simple (if we got an image, just check for a parent link and prefer that one).

This will however disable the possibility of dragging linked images into an image editor. I don't know whether it is possible of having a linked image dragged with link AND image data (prioritizing the first).

Comment 8

[Mike Shaver (:shaver emeritus)]

Clearing blocking: not clear that we actually want the proposed behaviour.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

My instinct is that most times when a user drags an image to the desktop, they mean to take the image, not the link. This is partially informed by the notion that if a user means to save a link, they would more often drag to a link-saving-area such as the bookmarks folder or the bookmark toolbar.

In chatting with mconnor, he proposed that any user who really wanted the image beneath the link would use RCSA, yet I feel that right-click behaviour is more prevalent for copying and pasting URLs between apps.

Also, a quick survey of some major web properties:

 http://www.cnn.com
 http://www.amazon.com
 http://www.ebay.com

Show that a lot of times images are used as redundant links for things that also have link targets in text near or beside them. I think people would be more likely to drag the text-link to get the link object on their desktop, and would expect that the image-drag would drop the image on their desktop.

Comment 10

[Simon Bünzli]

As I see it, many linked images on the three pages you mention are used instead of text links for better appearance. I doubt that anyone would want to drag these images to a folder. Of course you could try to distinguish small linked images (rather used as text replacements) from bigger linked images (although IME they rather point to an even bigger image).

A different question: how many people know about dragging links and how many people know about dragging images? I uninformedly suspect that there are more of the former and would thus tend to rather not disappoint them.

Finally: IE6 does prefer link over image (and Opera seems not to support drag&drop outside the browser).

Fortunately, no matter what gets decided here, it is possible for extensions to overrule the default...

Comment 11

[Simon Bünzli]

Attachment: prefer link over image

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 225113 [details] [diff] [review]
prefer link over image

ow this code.

That said, I don't see consensus here from the UI folks, and I don't see representatives of non-Firefox Gecko-based apps (who would all be affected by this change) cced on this bug.  Until that happens and they buy into the change, I don't think we should make it even if it's technically correct.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #10)
> A different question: how many people know about dragging links and how many
> people know about dragging images? I uninformedly suspect that there are more
> of the former and would thus tend to rather not disappoint them.

That's funny. I would argue exactly the opposite.

Also, the relative value of dragging a link to an image as opposed to dragging the image itself seems to be worth questioning here. Why would I want a link to the image on my desktop, when I could just have the image itself?

Comment 14

[Simon Bünzli]

(In reply to comment #13)
> Why would I want a link to
> the image on my desktop, when I could just have the image itself?

This is not about linking to the image itself but the the target which the link containing the image points to. E.g. dragging

<img src="http://www.example.org/image.png">

will still get you the image itself, but dragging

<a href="http://www.example.org/page.html"><img src="http://www.example.org/image.png"></a>

should give you a link to page.html rather than the image (which in this case was used instead of a text link).

To see the difference, go to cnn.com and drag the "World" and "E-Mails" links from the blue bar to your desktop. Why should the user not get two links in this case?

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

This is precisely the reason why we should always do the same thing consistently; otherwise it will be nigh impossible for a user to predict whether or not they'll be able to drag an image to their desktop if they want the image, not the link.

I would recommend WONTFIX for this one.

Comment 16

[Simon Bünzli]

I hope that you do understand that I just made the very same argument (except for fixing this bug): the user shouldn't have to know that of the two CNN.com links I mentioned above only one can be dragged to the desktop because the other one is an image.

We're not talking consistency here, but priority. And I still haven't heard an argument for why we should prefer images over links, given that
* a hyperlink is one of the most basic www units whereas images can even be turned off
* a lot of linked images I've seen are either obviously replacing text (menus, icons, etc.) or linking themselves to a bigger version of the same image; I fail to see why you'd still prefer to drag the image to your desktop
* if you right-click on a (linked) image, you'll get an option to save the image to the disk, but you don't get the same for the link itself, meaning that it's a PITA to create a .URL shortcut for a linked image (right-click -> Copy Link Location, switch to Explorer, right->click -> New -> Shortcut -> somehow paste the link -> Next -> give it a name -> Finish)  whereas it's be still quite easily possible to save the image
* and as mentioned the over-80%-user-share browser does it (even maybe backed by a usability study), so those users who know about drag&drop and convert will have to do without

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #16)
> I hope that you do understand that I just made the very same argument (except
> for fixing this bug): the user shouldn't have to know that of the two CNN.com

Uh, yes. But there is a flaw in your argument. You assert that we should be emphasizing consistent behaviour. I agree with that assertion. Of the set of all images on the internet, some are links, yet all are images. Thus, we should consistently perform the action that applies to the entire set, not a portion of the set.

Creating a link on the desktop when image is a link and creating a file when an image is not a link is inconsistent behaviour *unless* the user understands that the image is a link.

Always creating a file on the desktop regardless of whether or not an image is a link only requires that the user understand that the object they are dragging is an image.

So perhaps this is where we disagree: you are asserting that users will interpret images-in-anchors as links, and I am asserting that they will interpret them as images. I believe that I am right because:

 - there is often very little indication that an image is also an anchor 
 - an image looks different from text, and aside from cases where people are
   using images to substitute for text, are always image-like in quality 

> We're not talking consistency here, but priority. And I still haven't heard an

Wait. You were just arguing for consistency, now you're arguing for priority. But sure, I can swing this way, too :)

> * a hyperlink is one of the most basic www units whereas images can even be
> turned off

We're not talking about the case where images are turned off, we're talking about browing at all times. If this bug was "Dragging linked images to Finder/Explorer should make shortcut when images aren't loaded", I'd support it. Or wait, I'd mark it WORKSFORME, since that's what Firefox already seems to do.

> * a lot of linked images I've seen are either obviously replacing text (menus,
> icons, etc.) or linking themselves to a bigger version of the same image; I
> fail to see why you'd still prefer to drag the image to your desktop

Define "a lot". Greater than the number of images that are not replacing text? By an order of magnitude? I used to see this practice a lot, but it's been declining in popularity as the web moves towards CSS and alternative methods of getting pretty text in web pages. To be honest, I see more sIFR than I do rendered-text these days. By your own argument of priority for the majority case, though, we should prioritize for the more common use of images, which any quick survey of Alexa's Top 100 will show you is, unsurprisingly, pictures, not text.

> * if you right-click on a (linked) image, you'll get an option to save the
> image to the disk, but you don't get the same for the link itself, meaning 

This is, IMO, the only solid argument you've made, but I don't think it's compelling enough to outweigh the argument of consistency, and it can easily be covered by having an accel-drag create a link (when one exists.) I am not opposed to enabling some form of quick action. I am opposed to inconsistency in the UI which will make it hard for users to predict the outcome of an action.

> * and as mentioned the over-80%-user-share browser does it (even maybe backed
> by a usability study), so those users who know about drag&drop and convert 
> will have to do without

Do you have a cite for the usability study? Is it current? Let's not play the game of "maybe there's stats and reason behind why IE did it that way" game, because it leads us into a world of hearsay and speculation.

Comment 18

[Simon Bünzli]

(In reply to comment #17)
>  - there is often very little indication that an image is also an anchor 
Except maybe the fact that the cursor changes and that you get an outline around it on mouse-down. :)

>  - an image looks different from text, and aside from cases where people are
>    using images to substitute for text, are always image-like in quality 
The same argument could of course also be made for links (that even when they're applied to an image, they are always "link-like" in quality).

> Wait. You were just arguing for consistency, now you're arguing for priority.
I'm doing both, it's just that we don't agree on what should be consistent, which makes it a matter of priority.

> We're not talking about the case where images are turned off, we're talking
> about browing at all times.
Of course. I was just pointing out that while images can be turned off, hyperlinks can't and should thus be preferred because people rather think in "links" than in "images". Oh, ignore that, we both don't know how "people" think.

> By your own argument of priority for the majority
> case, though, we should prioritize for the more common use of images, which any
> quick survey of Alexa's Top 100 will show you is, unsurprisingly, pictures, not
> text.
Wouldn't this rather mean that we would have to prioritize for the more common use of links, which as you will see is that of linking somewhere instead of just hanging around an image? But then again, the argument gets circular (you looking at images, me looking at links).

> This is, IMO, the only solid argument you've made, but I don't think it's
> compelling enough to outweigh the argument of consistency, and it can easily be
> covered by having an accel-drag create a link (when one exists.) I am not
> opposed to enabling some form of quick action. I am opposed to inconsistency in
> the UI which will make it hard for users to predict the outcome of an action.
I will repeat it once more: both alternatives are consistent, one just prioritizes images while the other one prioritizes links. If you insist on an alternative solution - so be it.

> Let's not play the
> game of "maybe there's stats and reason behind why IE did it that way" game,
That wasn't the intention. The argument was that of being-consistent-with-IE not that of IE-knows-better.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

> Except maybe the fact that the cursor changes and that you get an outline
> around it on mouse-down. :)

To see that you must swipe over something and mouse down. A user will have decided what their desired task is (based on expected functionality of and past experience with the underlying system) before that, which will lead to them initiating an action. Swipe-to-discover-function UI is commonly used (see: the dock in OSX) but that doesn't mean it is usable.

> >  - an image looks different from text, and aside from cases where people are
> >    using images to substitute for text, are always image-like in quality 
> The same argument could of course also be made for links (that even when
> they're applied to an image, they are always "link-like" in quality).

You are talking about the attributes of the underlying system (ie: the HTML anchor) and I am talking about what the user experiences (ie: a picture vs. text).

> I'm doing both, it's just that we don't agree on what should be consistent,
> which makes it a matter of priority.

Well, we don't agree on how the majority of users classify an IMG within an A. You seem to think they see it as an A that happens to be an IMG, I think that they see it as an IMG that might well be an A. :)

> Of course. I was just pointing out that while images can be turned off,
> hyperlinks can't and should thus be preferred because people rather think in
> "links" than in "images". Oh, ignore that, we both don't know how "people"
> think.

See above; this is based on an assumption that people think of the underlying system (ie: a set of pages linked together) rather than simply the content being shown to them (ie: words and pictures). I would rather promote content over the system, since the user's task is to be connected to content.

> Wouldn't this rather mean that we would have to prioritize for the more common
> use of links, which as you will see is that of linking somewhere instead of
> just hanging around an image? But then again, the argument gets circular (you
> looking at images, me looking at links).

Sure does! :) Once again, we see the difference in the way we're approaching this debate. Put plainly: I don't think the majority of users see images that are links as links, but rather as images that happen to do something funky when you click them. I believe that the first thing that a user thinks when they see a picture of an arrow is "It's an arrow", and then they might think "I bet clicking that takes me to the next page." I do not believe that they think "It's a link to the next page," and then "and it's a picture of an arrow."

> I will repeat it once more: both alternatives are consistent, one just
> prioritizes images while the other one prioritizes links. If you insist on an
> alternative solution - so be it.

Agreed.

> That wasn't the intention. The argument was that of being-consistent-with-IE
> not that of IE-knows-better.

FWIW, and as I'm sure you know, we do a lot of things that IE doesn't if we think that our way is better interpreting the user's mental model and desired task.  :)

I'm pretty sure we've exhausted the debate here, although it certainly has been interesting. Not sure where to go, other than perhaps up to module owner?

Comment 20

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.