[Confirmed] in 2.0.164.0.

This worked properly before.  Add label: Regression

What I'm seeing is that the "alt text", if any, becomes the name of the dropped
image.  If there is no "alt text", the filename of the image becomes the name of the
dropped image.

So, for example:

<img src="hills.jpg" alt="This is the alt text">
The dropped image is named "This is the alt text.jpg".

<img src="hills.jpg">
The dropped image is named "hills.jpg".

Is this what you're seeing?

Yes, it seems like the "alt" text becomes the dropped filename.... which is quite simply 
the wrong thing to do!  And this also applies to the "title" attribute in case the <img> 
tag has a "title" attribute.  Do *not* use either of these attribute values for the dropped 
filename no matter if they exist or not.

And this applies no matter if the loaded resource is a simple filename or a complex request 
query.  For example:
  someimage.jpg
  someimage.jpg?parm1=val1&parm2=val2
  somescript.php?parm1=val1&parm2=val2 (that returns something that is an image MIME type)

all should the dropped with their _resource names_.  In the second and third cases above, 
it will probably result in a generated filename without the proper extension and not 
directly openable in the OS, but that is _to be expected_.

Regardless, you cannot use any of the "alt" or "title" values to generate the dropped 
filename.

Dropping the image should use the same filename as right-click > Save Image As, which 
is to use the filename of the resource.  See  Issue 7023 

OK, confirmed. Thanks to adonnod and dhhwai.

(No comment was entered for this change.)

Sounds like some stuff Adam has worked on.

I'll see if I can fix it...

This is a WebKit issue... Safari 4 suffers from the same thing...

Makes sense since the code handling the drop is in WebKit's Node event dispatch code.

I couldn't find a bug for this on bugs.webkit.org, so I'll create one and add a 
double-link to and from this one...

Here's the WebKit bug link: https://bugs.webkit.org/show_bug.cgi?id=24887

Weird... I found the code setting the value, and it is on the platform/chromium side...

Seems like Safari 4.0 foe Windows made the same mistake we did then (or vice versa) :-) The Mac version does the right 
thing BTW. The win version do the same mistake in the platform/win version of the code (though the code is different, the 
end result is the same). I'll update the WebKit bug with the relevant info for them.

Here's the info for us:

in third_party\WebKit\WebCore\platform\chromium\ClipboardChromium.cpp
ClipboardChromium::declareAndWriteDragImage() calls writeImageToDataObject()
This static function has the following code:
    // Determine the filename for the file contents of the image.  We try to
    // use the alt tag if one exists, otherwise we fall back on the suggested
    // filename in the http header, and finally we resort to using the filename
    // in the URL.
    String extension = MIMETypeRegistry::getPreferredExtensionForMIMEType(
        cachedImage->response().mimeType());
    dataObject->fileExtension = extension.isEmpty() ? "" : "." + extension;
    String title = element->getAttribute(altAttr);
    if (title.isEmpty())
        title = cachedImage->response().suggestedFilename();

    title = ClipboardChromium::validateFileName(title, dataObject);
    dataObject->fileContentFilename = title + dataObject->fileExtension;

And this is why we get the <alt> text instead of the actually filename from the URL as when we save image and as we see as 
a behavior of Safari 4 on Mac. I'll check with the people who wrote the code above to see if there is a good reason for 
this.

I have a fix coming, will get it reviewed by tc who seem to be the original author...

(No comment was entered for this change.)

I have a fix in the pipeline on the WebKit side:
https://bugs.webkit.org/show_bug.cgi?id=24887

Moving to mstone 3 from an older milestone.  Need to triage.

Moving to milestone 3 from an older milestone.  Need to triage.

Is there a good way to come up with a regression test for this, pref not a UI unit 
test.

This seems like a webkit bug.

related issue: Issue 16318

Dumi, I thought you were somewhere in whereabouts of this code w/HTML5 database file 
handling. Can you take a look?

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Looking at the WebKit bug, Marc-André Decoste had a fix almost ready but then disappeared in mid-April.
His fix looks good, but it was pointed out that it should go into shared code so that all platforms can use it.
I'll pick it up and start working on it.

Jens, have you made progress on this?

I was making progress, but have been on vacation all last week. Back now, though.

FYI, I've just submitted a new patch over at the WebKit bug report.

Changing the status to Upstream because Jens is working his way through the review 
process on his patch.  This fix touches a lot of interesting edge cases and we have a 
bunch of patch revisions.  Still need a test for this to be accepted into WebKit.

As we would not block the 3.0 beta release for this I am moving it to mstone-4.  
However the sooner we get this fix the better.  It would be great to get it into 3.0.

Status: WebKit reviewers required a test case. Specifics of drag-and-drop API on Mac OS make writing a test for 
this nearly impossible without putting lots of hacks into WebKit, so we compromised on requiring a Windows 
test.
I've been bringing up a Windows dev environment and building WebKit on it. Unfortunately the first thing I 
discovered is that all dragging on Windows is currently broken: dragging anything inside a web view causes a 
crash. This was reported a month ago as 27332 but no one seems to have investigated it yet. That pretty much 
stymies me from writing any test cases until that bug is fixed.

does this mean this won't be resolved for Milestone 4? What's the next step here?

I think it's pretty much stuck until someone fixes drag-n-drop for Windows WebKit (not Chromium).

Is this moving now?

(No comment was entered for this change.)