Custom drag types are not exposed to other applications
Reported by
tilman.s...@gmail.com,
Mar 2 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4 Example URL: http://jsfiddle.net/tilmans/72adajrg/1/ Steps to reproduce the problem: 1. Drag first link to test app (text/plain) 2. Observe payload being available 3. Drag second link to text app (custom type) 4. Observe payload is not available What is the expected behavior? Custom data types should be included in the drag data, not just standard types What went wrong? These exact steps work on Safari. Chrome on Windows seems to have the same issue. Chrome is only handing out standard data types such as text/plain. This was already described at https://bugs.chromium.org/p/chromium/issues/detail?id=93514 and the issue was incorrectly closed. I've attached a simple native app for testing. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 48.0.2564.109 Channel: stable OS Version: OS X 10.11.3 Flash Version: Shockwave Flash 20.0 r0
,
Jul 15 2016
,
Jul 19 2016
This is more or less working as intended. Allowing web content to control arbitrary types on the clipboard leads to the potential for sandbox escapes (for example, with RTF parsing vulnerabilities). In addition, there are platform limitations that a hostile page could exploit to DoS your system: for example, on Windows, just calling RegisterClipboardFormat() and writing the data through means a page could exhaust the atom table in a way you can't easily recover from. |
|||
►
Sign in to add a comment |
|||
Comment 1 by ellyjo...@chromium.org
, Mar 3 2016