[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
Regression window: https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=46045ec8a4aa09a341b7209170089ade3c27c1a5&tochange=71c8d652e638dd67c5c56879df83d76b30033458 Regressed by: Bug 664717 This is e10s only problem.
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')
(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.
Track 51+ as regression.
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.
Moving tracking flag for 51 over to duplicate bug.
Marking fixed in 52 since the dupe (bug 1308007) has that set.