1458453 - "Copy Image" from http webpage (vs https) places invalid file in clipboard CF_DHROP, causes pasting problem

Status: RESOLVED WORKSFORME

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

Description

[fireattack [:fireattack]]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.18 Safari/537.36

Steps to reproduce:

1. Install Clipboard Format Spy (http://delphidabbler.com/software/cfs/main ) or any similar problem to investigate clipboard.
2. Open [MAY CONTAIN NSFW AD] https://e-hentai.org/s/b4cb449778/1217096-4 
3. right click on the image (not ADs) and "copy image"
4. Check Clipboard Format Spy, find the entry "CF_DHROP", double-click.
5. You can see a file path which is supposed to locate in your temp folder.



Actual results:

That file is a 0kB file. It's invalid and can't be opened.


Expected results:

That file in CF_DHROP should be a cached version of that image.

Actually, if you use "Copy Image" from the image direct link page ( Here it is http://96.255.206.172:44444/h/4d4f13fd01ba0ee0b3a1d4238b433c87efbde8a2-22390-200-281-jpg/keystamp=1525242600-933e227177;fileindex=60404423;xres=2400/3d4d8880044ba32b25c7be05ed447f2a.jpg , your actul URL could be different), it will generate the correct file in your temp folder.

This will cause problem when pasting images into other applications when pasting images, if they rely on CF_HDROP. A famous example is QQ (the most popular instant messaging software in China).

This bug has the exactly same symptom as bug 1340039 (which was supposed to be fixed, see also: bug 1342740). According to the Assignee there the root cause may be different; this one may be caused by mixed content.

This is a regression. Unfortunately, mozregression cannot give a more precise bisect, all I know is 

2016-08-03 Good
2016-08-04 Bad 

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6608e5864780589b25d5421c3d3673ab30c4c318&tochange=1576e7bc1bec7232e9e4ba78cce62526b1a6380b

Comment 1

[Hector Zhao [:hectorz]]

I'm using https://www.bennish.net/mixed-content.html to confirm my initial guess:

With the image served thourgh http, copying the image fails with:

> 
> [Parent 14520, Main Thread] WARNING: NS_ENSURE_TRUE(docShell) failed: file d:/mozilla/gecko-dev/dom/security/nsMixedContentBlocker.cpp, line 721
> [Parent 14520, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805E0006: file d:/mozilla/gecko-dev/dom/security/nsContentSecurityManager.cpp, line 659
> [Parent 14520, Main Thread] WARNING: 'NS_FAILED(rv)', file d:/mozilla/gecko-dev/netwerk/protocol/http/nsHttpChannel.cpp, line 6137
> [Parent 14520, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805E0006: file d:/mozilla/gecko-dev/widget/windows/nsDataObj.cpp, line 87
> [Parent 14520, Main Thread] WARNING: NS_ENSURE_TRUE(pStream) failed: file d:/mozilla/gecko-dev/widget/windows/nsDataObj.cpp, line 1707
> 

With the image changed to its https equivalent, copying the image works as expected.

I have no clue about how this could be fixed.

Comment 2

[laszlo.bialis]

Daniel/Hector could you please suggest a more appropriate Component for this issue?

Comment 3

[Andrew Overholt [:overholt]]

Christoph, could this be a change from bug 1143922? Do you have any thoughts about how we could fix this issue?

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Andrew Overholt [:overholt] from comment #3)
> Christoph, could this be a change from bug 1143922? Do you have any thoughts
> about how we could fix this issue?

Sorry, I don't have the time to look into myself at the moment, but potentially I can provide some insights which might help someone to get started.

So, the problem is related to mixed-content-blocking, as indicated within comment 1. If served over HTTPS, the problem disappears because the Mixed Content Blocker does not see any reason to become active. If served over HTTP over, the Mixed Content Blocker becomes active. The problem might have become visible by the changes within Bug 1143922 because since then we perform checks in the child and in the parent. However, since we can't serialize the document and docshell, the mixed content blocker might bail in the parent with the error indicated in comment 1.

The Mixed Content Blocker should allow load, because images are mixed display content and the only reason we block it is because we can't query the docshell. To start, I would check if adding the following lines within nsMixedContentBlocker::ShouldLoad() fixes the problem:

if (XRE_IsParentProcess()) {
  return;
}

Please also check the UI right next to the URL-Bar which should indicate that mixed display content is loaded.

HTH!

Comment 5

[fireattack [:fireattack]]

Any progress on this? It has been broken for 2+ years (see also: bug 1340039).

If no one wants to take time to fix it properly, can we at least revert the regression patch (bug 664717) that caused it?
Making copying ANY image unreliable is not acceptable cost for fixing GIF copy problem.

Comment 6

[Mirko Brodesser (:mbrodesser-Igalia), offline until May 27st]

Is this still an issue? (I'm not using Windows)

Comment 7

[fireattack [:fireattack]]

The original STR no longer exists, but I tried a few mixed-content test pages and copying works now.

Comment 8

[Edgar Chen [:edgar]]

Per comment #7.