Closed Bug 1013211 Opened 8 years ago Closed 7 years ago

Drag and Drop images sometimes are corrupt


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

32 Branch
Not set



Tracking Status
firefox32 + wontfix


(Reporter: lh.bennett, Assigned: mats)




(Keywords: reproducible, Whiteboard: [STR in comment 9])


(2 files, 1 obsolete file)

Dragging and dropping an image either on desktop or any other folder can sometimes cause the file not to be saved correctly. It seems to happen at random. Refreshing the page can somnetimes result in a proper save with drag and drop.

Might be due to cache2, but reporting it here anyway.
Severity: normal → critical
Ever confirmed: true
Version: Trunk → 32 Branch
Can you please expand your description with steps to reproduce. Is there a specific site on which you have noticed this happening more frequently? Does this impact jpg, png, gif, other image formats? Into what folder are you attempting to drop the image?

As well, what version of Firefox are you currently using and when did you first notice this? This bug is marked as 32 branch. Are you currently using Firefox Aurora?
Flags: needinfo?(lh.bennett)
Leman - Can you still reproduce this issue?
Yes. I see this most often at DeviantART. But its quite random. At Deviantart downloaded images opens up in a window. From there, you just drag it to the desktop or another folder in Windows Explorer. I've seen this less often elsewhere but there were others who complained about the issue happening elsewhere which is why I filed.
Flags: needinfo?(lh.bennett)
I'm marking as qawanted as we'll need to reproduce and determine a regression window if we are to make progress. Given where we are in the 32 beta cycle, I think that it is unlikely that this will be fixed in 32 but am going to leave tracking for now to try and get some action on this bug.
Keywords: qawanted
With no progress and the end of the beta cycle approaching, I'm marking this as won't fix for 32. As I said in comment 4, we'll need STR and a regression window if we are to proceed on this bug.
I gave this a try today on Windows 7 x64 with Firefox 32.0.3 (BuildID: 20140923175406), but I was unable to reproduce this. 

Here's what I tried:
1. Went to
2. Clicked on a picture.
3. Dragged picture to desktop/folder.
4. Clicked Next to get to next picture.
5. Repeated steps 3 & 4 do drag multiple pictures (one after another) to Desktop/Folder.
6. After several tries, deleted pictures, then used Back to download some of the same pictures.

I encountered no issues, as pictures were correctly saved at each step. 

I'll also try to reproduce this on Win 8.1 x64, but I would like to know if the scenario above is similar to what you are doing when getting this problem Leman. Are you having any connectivity issues (slow connection) when doing this? Could you please see if you can provide us with some more information? Thank you in advance.
Flags: needinfo?(lh.bennett)
One more thing that I forgot Leman... could you tell us with approximation how often you see this?... e.g. once a day, or once every 10 pics... for deviantart at least.
Ok, lets get basic:

1. Visit this link:

2. Click "Download".

3. Drag and drop the picture to the desktop.

There's a 50/50 chance that it won't save correctly. If it doesn't you won't get a working copy until you REFRESH. This happens at random. I have no other solid steps to reproduce something so flaky and unpredictable. This has been also reported by others as happening on other sites. They also did not have a method for reproduction other than Drag and Drop. Sounded simple enough.

This is and was reported on Windows, so that's a good place to start. Also, I have a 50Mbit stable connection, it rarely has issues, so I do not blame my ISP for this issue when other browsers perform fine.
Flags: needinfo?(lh.bennett)
I've tried this yesterday on Win 7 x64 with Firefox 32.0.3 with no success whatsoever.

Today I got my hands on a Win 8.1 Pro x64, and tried this again, but still no success.

Scenario tried:
1. Started Firefox with new profile.
2. Visited link:
3. Clicked on "Download" at the right of the picture.
4. When picture opened in a new window covering the whole screen, I dragged it, <Win>+D to get to Desktop, and dropped the picture on the desktop (alternatively tried in a folder from the Desktop).

Results: in all cases the picture was saved just fine and opened correctly (must have been at least 50 tries). Note that I've also tried small variations like changing size of the window, zoom, full screen, opening from different tabs/windows. Also, tried to repeat the same scenario, tried consecutive downloads, tried with new profiles, multiple times on various versions.

Builds tested:
- Firefox 32.0.3 - BuildID=20140923175406
- Firefox 33.0 RC - BuildID=20141007073543
- Firefox 34 Aurora latest - BuildID=20141009004002
- Firefox 35 Nightly latest - BuildID=20141009030201

Unless someone has an idea of what could be causing this behavior, or unless this is deemed critical, we cannot spend any more time investigating this.

My only remaining ideas would be long term use causing some problems, or some 3rd party software/add-ons. Leman, do you think you could try with:
A. Other new profile:
B. Safe Mode:
Attached image Network Tool screenshot
I think that I may or may not found the issue with deviantart at least. I've attached a screenshot.

The dragged image says that its a PNG. But its not. 

The popup that masquerades as an image in a window is actually an HTML page:

<html><head></head><body style="padding:0;margin:0;background:#76827B"><img src=";ts=1415360955"></body></html>

Pushing this corrupt file through a text editor, I found out that its HTML itself. Its some sort of redirect. Firefox thinks that its a PNG when dragged and will proceed to save it as such:

<html><head><title>Redirection</title></head><body><script>type="text/javascript">window.location.href="http:\/\/\/art\/desktop-positive-quote-493062043"</script><noscript><a href="">Click here to continue.</a></noscript></body></html>

Using page info will show that Firefox thinks that its a PNG with 0px, 0px size and uncached.

I also have a video of the drag and drop process in case this wasn't enough evidence.
Flags: needinfo?(lh.bennett)
(In reply to Leman Bennett [Omega] from comment #11)
> The popup that masquerades as an image in a window is actually an HTML page

I get the same result using the STR in comment 9 (on Linux).

So I debugged this a bit: the following javascript runs when clicking
the Download button (heavily edited to show the essence):

  var href = ''
         s.document.write('<html><body style="padding:0;margin:0;"><img src="'+href.replace(/"/g,"&quot;")+'"></body></html>'),

The document.write string above is what you see in Page Source.
When we load the image URL there, we get a Content-Type:"text/html"
Content-Length:"0" response which is a 302 redirect to
which contains the actual image.

Page Info (CTRL+I) - Media tab, shows the 'src' attribute value in Location
(not the final destination), Size:0 and Type:JPEG.

When I drag the image to the desktop it's saved as .jpg but contains HTML
(the "Redirection" content as in the last comment).

(If I instead choose "View Image" in the context menu and then drag that,
then the real image is saved.)

It seems this site is going to great lengths NOT to let you download
the actual image, but instead give you a HTML file that redirects
back to the site.  It's certainly confusing to the user since it
appears you're dragging and saving an image when you're not.
OS: Windows 8.1 → All
Hardware: x86_64 → All
I'm guessing that when we start dragging an image we simply use the
"src" attribute value when instead we should use the final URL the
image data came from.  Same for Page Info.
Attached patch fix (obsolete) — Splinter Review
This seems to work fine for me on Linux.  imgRequest::mCurrentURI has the final
image URI so we just need to expose it and use that instead:
Leman, could you test the build on Windows and let me know if it works correctly for you?
Flags: needinfo?(lh.bennett)
I had to revert e10s to avoid the crashing but it seems to work with the affected links I've thrown at it so far.
Flags: needinfo?(lh.bennett)
Great, thanks for testing it!
Attached patch fixSplinter Review
1. Expose read-only access to imgRequest::mCurrentURI
2. use that when dragging an image (s/GetURI/GetCurrentURI/)

I also changed the order in DragDataProducer::Produce so that if don't
reach the imgRequest::GetCurrentURI call for whatever reason we still
use the old code as fallback.

Added an extra line to the PR_LOG output for redirects so that it
prints the new URI as well as the old, and added a LOG_TEST macro
to avoid doing string copies (GetSpec) when logging isn't active.
Assignee: nobody → mats
Attachment #8519231 - Attachment is obsolete: true
Attachment #8519433 - Flags: review?(roc)
I don't think there is any dataloss here in the normal sense of that keyword.
Failing to save an image from the net isn't dataloss.  This isn't a regression
in our code - I can reproduce it FF3.6 on Linux.  It most likely broke because
the site added a redirect that wasn't there before.
Whiteboard: [STR in comment 9]
Try link please :)
Keywords: checkin-needed
There were only minor changes compared to the first patch that has a Try run,
so it didn't seem worth it.
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Depends on: CVE-2015-4519
You need to log in before you can comment on or make changes to this bug.