1307999 - [e10s] No Images Created when using CTRL-V (copy image from Yahoo Image Search) on SimpleUploads for CKEditor demo page

Status: RESOLVED DUPLICATE of bug 1308007

(Core :: Widget, defect)

Description

[Alice0775 White]

[Tracking Requested - why for this release]:

+++ This bug was initially created as a clone of Bug #1305163 +++

Build Identifier:
https://hg.mozilla.org/mozilla-central/rev/ea104eeb14cc54da9a06c3766da63f73117723a0
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 ID:20161005030211

Problem occurs in Yahoo Image Search results on Aurora51.0a2 and Nightly52.0a2.
But Problem does not occur in Google Image Search results.


Steps to reproduce:
1. "Copy Image" on Yahoo Image Search results(https://images.search.yahoo.com/yhs/search;_ylt=A86.J3WMbvVXGhYAGoInnIlQ?p=moz&fr=yhs-mozilla-001&fr2=piv-web&hspart=mozilla&hsimp=yhs-001)
2. Open http://www.martinezdelizarrondo.com/ckplugins/simpleuploads.demo4/
3. Click the editor
4. Attempt paste it (Ctrl+v)


Actual results:
  No image is created


Expected results:
  Image should be created

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=46045ec8a4aa09a341b7209170089ade3c27c1a5&tochange=71c8d652e638dd67c5c56879df83d76b30033458

Regressed by: Bug 664717


This is e10s only problem.

Comment 2

[Alfonso Martinez]

The problem is exactly the same as explained in https://bugzilla.mozilla.org/show_bug.cgi?id=1308007#c2 the call to DataTransferItem.getAsFile() returns null (despite item.kind == 'file')

Comment 3

[Hector Zhao [:hectorz]]

(In reply to Alice0775 White from comment #1)
> 
> Regressed by: Bug 664717

I'm not really familiar with these clipboard/drag-n-drop related code, and I feel I'm not capable of fixing this.

(In reply to Alfonso Martinez from comment #2)
> The problem is exactly the same as explained in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1308007#c2 the call to
> DataTransferItem.getAsFile() returns null (despite item.kind == 'file')

For reference, a few things I noticed in my debugging attempt:
1. Before my change, there's three `DataTransferItem` in the paste event: string(text/html), file(image/png) & string(image/jpeg) (even when a gif is copied into the clipboard); now it's just one: file(application/x-moz-file);
2. It looks like adding `application/x-moz-file-promise` flavor to a nsITransferable will implicitly add `application/x-moz-file`, I'm not sure how that happens;
3. I'm inclined to think my patch happens to introduce the `application/x-moz-file` flavor into the nsITransferable, while the root cause is the same as bug 1308007. :mystor, maybe you can help me deciding whether that's the case? Thanks.

Comment 4

[Gerry Chang [:gchang]]

Track 51+ as regression.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

As far as I can tell this is caused by a combination of hector's bug switching us to using x-moz-files for these images, and the fact that those are not handled nicely during synchronous IPC calls currently. Marking as duplicate.

Comment 6

[Marcia Knous [:marcia]]

Moving tracking flag for 51 over to duplicate bug.

Comment 7

[Andrew Overholt [:overholt]]

Marking fixed in 52 since the dupe (bug 1308007) has that set.