[non-e10s] Paste image data doesn't work properly with e10 disabled

NEW
Unassigned

Status

()

Core
DOM
P3
normal
a year ago
a year ago

People

(Reporter: cbadau, Unassigned)

Tracking

Trunk
x86_64
Windows
Points:
---

Firefox Tracking Flags

(firefox53 affected, firefox54 affected, firefox55 affected)

Details

[Affected versions]:
- Firefox 53 Beta 2
- latest Aurora 54.0a2 (2017-03-15)
- latest Nightly 55.0a1 (2017-03-15)

[Affected platforms]:
- Windows 7 x64
- Windows 10 x64

[Steps to reproduce]:
1. Start Firefox and visit https://mystor.github.io/dragndrop/.
2. Select paste-image-data from the demopage.
3. In a new window visit a webpage with many images(e.g: http://1stwebdesigner.com/image-file-types/)
4. Select an image from the website and copy it to clipboard (Right click an image and select Copy image). 
5. Select Drop Stuff Here! area from demopage and paste the image copied earlier (CTRL+V). 

[Expected result]:
- "Matching" appears under the Drop Stuff Here area, the expected result is identical to the result.

[Actual result]:
- "Not matching" appears under the Drop Stuff Here area. 

Result

kind: paste

types:
  [0] application/x-moz-file
  [1] Files

file count: 1

items:
  [0] file - image/jpeg


Expected Result

kind: paste

types:
  [0] text/html
  [1] Files

file count: 1

items:
  [0] string - text/html
  [1] file - image/png

[Regression range]:
- TBD

[Additional notes]:
- This issue is reproducible only with e10s disabled.

Comment 1

a year ago
This is probably related to bug 1308007. Namely, it appears as though copying image data on windows causes it to look like a file was copied to the clipboard, and in the non-e10s case, the file handling case takes over, while in the e10s case, the file fails to transmit to the content process, and thus we fall back to a normal image.
See Also: → bug 1308007
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.