[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 local image on Beta50.0b4, Aurora51.0a2 and Nightly52.0a2. Steps to reproduce: 1. Open local image with "Windows Photo Viewer"/"Photo" 2. Right clock on the image and "Copy" 3. Open http://www.martinezdelizarrondo.com/ckplugins/simpleuploads.demo4/ 4. Click the editor 5. Attempt paste it (Ctrl+v) Actual results: No image is created Expected results: Image should be created

Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b2409b36cd07bba045bf38dd131166c36ea3da4a&tochange=3d0aef4586bdbd81591811ec627c85161fc11065 Suspect: Bug 906420

I've tested with 51.0a2 (2016-10-07) (32-bit) and the issue is that the event clipboardData object has a "items" property, a DataTransferItemList with one item That item has .kind == "file", but calling .getAsFile() on it returns null and I didn't expect that so the code crashes. I've adjusted the code to ignore that bad file contents and now the code doesn't crash and the image is pasted due to the rest of the detections. But so it turns out that now it's no longer possible no copy a file from Explorer (like a .zip or .pdf) and paste it in the editor to upload it directly (this still works in 50.0b4) Disabling e10s makes the paste work correctly again

[Platform Triage] To Michael for a look.

Files are not correctly transmitted over ipc, due to http://searchfox.org/mozilla-central/source/dom/base/nsContentUtils.cpp#7804-7821. We need some mechanism for being able to transmit these files synchronously over IPC such that the clipboard copy-paste functionality works correctly with files when e10s is enabled.

Tracking 52+ for this regression - copy and paste seems to be a common operation. I also carried over the 51+ flag from the duplicate bug.

Tracked in 50 as it's a new regression.

Michael told me he's working on a workaround (which will be in bug 1306645 in the near future) but he'd rather fix *this* bug in a better way. He's concerned about major regression fallout if he does anything other than the workaround so we'll likely have to punt on a proper fix here until at least 52. Maybe Blake will come back with something which is safe to uplift but offline he's expressed concern about that being possible. Once we have the patch on bug 1306645 I'll mark this fix-optional for 50/51 and maybe 52.

Given the patch on bug 1306645 having beta uplift approval, I'm going to mark this fix-optional for 50 and 51 (since the patch which will be uplifted there has branch-specific fixes that paper over this issue).

One possibility to try would be to somehow always have a blob half-constructed between each child and the parent process to use for this case. The reason that we do the hack pointed to by comment 4 is because trying to create a blob and use it in the return value of a synchronous message crashes when the child tries to use the blob before it has a chance to run the blob constructor (and changing the priority of the blob constructor is a definite non-starter). Having a half-constructed blob would get around that, but I don't know if there are other pitfalls lurking there.

No longer reproduce this problem on Beta50Rc1, Aurora51.0a2 and Nightly52.0a1. Fixed window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a6787db4d131dce2eabe0fab90c0e03e531190b5&tochange=3201c03e0c16fcba25c23af79cec8b08ea174ab7 Fixed by: 3201c03e0c16 Michael Layzell — Bug 1306645 - Don't add application/x-moz-file entries from the clipboard to dataTransfer with e10s, r=enndeakin

The underlying bug hasn't been fixed, just a workaround in bug 1306645. This bug is being used for the real fix.

This bug IIRC is caused by http://searchfox.org/mozilla-central/rev/876c7dd30586f9c6f9c99ef7444f2d73c7acfe7c/dom/base/nsContentUtils.cpp#7981-7999. In bug 1353629 there were some changes to how the blob constructor code works. My only understanding of these changes comes from baku's post on dev-platform, but it seemed to me from my quick reading of that email that we may be able to fix this problem with the new IPCBlob refactoring. Baku, is there any chance that you could take a look?

> Baku, is there any chance that you could take a look? I just tested it and it works. Can somebody else verify it, please?

Blake, as you wrote this code is there any chance you could remove the check now (as it should be safe to construct blobs over sync IPC now from what I understand). I imagine you'll know better than me what other concerns we could run into from the change being made.

(In reply to Michael Layzell [:mystor] from comment #16) > Blake, as you wrote this code is there any chance you could remove the check > now (as it should be safe to construct blobs over sync IPC now from what I > understand). I imagine you'll know better than me what other concerns we > could run into from the change being made. Hold on. Creating an Blob using a sync IPC is OK Child to Parent using IPCBlob. But parent to child it's not yet because PIPCBlobInputStream doesn't have a sync IPC CTOR. We can change it, but maybe we can find a better solution. Let me take a closer look.

We need to make the communication async. The current code doesn't resolve this issue.

(In reply to Andrea Marchesini [:baku] from comment #18) > We need to make the communication async. The current code doesn't resolve > this issue. Filed 1375022 to discuss ways to make Msg_GetClipboard async.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Pushed by evilpies@gmail.com: https://hg.mozilla.org/integration/autoland/rev/f9cc66c55a13 Add a pref to allow files in DataTransfer from paste again. r=nika https://hg.mozilla.org/integration/autoland/rev/d5c7e2162b99 Enable browser_clipboard_pastefile.js test. r=nika