1013211 - Drag and Drop images sometimes are corrupt

Status: RESOLVED FIXED

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

Description

[Leman Bennett [Omega]]

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.

Comment 1

[Lawrence Mandel [:lmandel] (use needinfo)]

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?

Comment 2

[Lawrence Mandel [:lmandel] (use needinfo)]

Leman - Can you still reproduce this issue?

Comment 3

[Leman Bennett [Omega]]

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.

Comment 4

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 5

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 6

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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 http://www.deviantart.com/.
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.

Comment 7

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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.

Comment 8

[Leman Bennett [Omega]]

Ok, lets get basic:

1. Visit this link: http://www.deviantart.com/art/Homecoming-486600496

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.

Comment 9

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

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: http://www.deviantart.com/art/Homecoming-486600496.
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: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
B. Safe Mode: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 10

[Mats Palmgren (inactive)]

Leman, do you think you could try with:
A. Other new profile: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
B. Safe Mode: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 11

[Leman Bennett [Omega]]

Attachment: 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="http://www.deviantart.com/download/493062043/desktop_positive_quote_by_cocorie-d85k13v.png?token=99e6d18dfdd2a69600cedc37e99eb260165ef257&amp;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:\/\/cocorie.deviantart.com\/art\/desktop-positive-quote-493062043"</script><noscript><a href="http://cocorie.deviantart.com/art/desktop-positive-quote-493062043">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.

Comment 12

[Mats Palmgren (inactive)]

(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 = 'http://www.deviantart.com/download/486600496/homecoming_by_kuldarleement-d81pjcg.jpg?token=ff2b0796f631c3ae9373e48aa0eed7458510d41f&ts=1415378199'
  return s.document.open(),
         s.document.write('<html><body style="padding:0;margin:0;"><img src="'+href.replace(/"/g,"&quot;")+'"></body></html>'),
         s.document.close(),
         s.focus(),!1

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
http://fc00.deviantart.net/fs70/f/2014/278/a/2/homecoming_by_kuldarleement-d81pjcg.jpg
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.

Comment 14

[Mats Palmgren (inactive)]

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.

Comment 15

[Mats Palmgren (inactive)]

Attachment: fix

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:
http://mxr.mozilla.org/mozilla-central/source/image/src/imgRequest.h?rev=b6414bb45f5d

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=aeb5d39d5e72

Comment 16

[Mats Palmgren (inactive)]

Leman, could you test the build on Windows and let me know if it works correctly for you?
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-aeb5d39d5e72/try-win32-debug/

Comment 17

[Leman Bennett [Omega]]

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.

Comment 18

[Mats Palmgren (inactive)]

Great, thanks for testing it!

Comment 19

[Mats Palmgren (inactive)]

Attachment: fix

1. Expose read-only access to imgRequest::mCurrentURI
http://mxr.mozilla.org/mozilla-central/source/image/src/imgRequest.h?rev=b6414bb45f5d#218
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.

Comment 20

[Mats Palmgren (inactive)]

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.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Try link please :)

Comment 22

[Mats Palmgren (inactive)]

There were only minor changes compared to the first patch that has a Try run,
so it didn't seem worth it.
https://hg.mozilla.org/integration/mozilla-inbound/rev/10573765ff5e

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/10573765ff5e