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

RESOLVED DUPLICATE of bug 1308007

Status

()

Core
Widget
RESOLVED DUPLICATE of bug 1308007
a year ago
a year ago

People

(Reporter: Alice0775 White, Unassigned)

Tracking

({multiprocess, regression})

51 Branch
x86
Windows 10
multiprocess, regression
Points:
---

Firefox Tracking Flags

(firefox49 unaffected, firefox-esr45 unaffected, firefox50 unaffected, firefox51 fix-optional, firefox52 fixed)

Details

(Reporter)

Description

a year ago
[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
(Reporter)

Updated

a year ago
OS: Windows 7 → Windows 10
Hardware: x86_64 → x86
Version: 50 Branch → 51 Branch
(Reporter)

Updated

a year ago
See Also: → bug 1308007
(Reporter)

Updated

a year ago
See Also: → bug 1305163
(Reporter)

Comment 1

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

Regressed by: Bug 664717


This is e10s only problem.
Blocks: 664717
Component: DOM: Events → Widget
Flags: needinfo?(bzhao)
Keywords: multiprocess
Summary: No Images Created when using CTRL-V (copy image from Yahoo Image Search) on SimpleUploads for CKEditor demo page → [e10s] No Images Created when using CTRL-V (copy image from Yahoo Image Search) on SimpleUploads for CKEditor demo page
(Reporter)

Updated

a year ago
Whiteboard: [DUPEME]

Comment 2

a year ago
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.
Flags: needinfo?(bzhao) → needinfo?(michael)
Track 51+ as regression.
tracking-firefox51: ? → +
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.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(michael)
Resolution: --- → DUPLICATE
Duplicate of bug: 1308007
Moving tracking flag for 51 over to duplicate bug.
tracking-firefox51: + → ---
tracking-firefox52: ? → ---
status-firefox51: affected → fix-optional
Marking fixed in 52 since the dupe (bug 1308007) has that set.
status-firefox52: affected → fixed
You need to log in before you can comment on or make changes to this bug.