Bug 33877 - HTML5: copy and paste should dispatch drag and drop events
Summary: HTML5: copy and paste should dispatch drag and drop events
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows Vista
: P2 Normal
Assignee: Nobody
URL: http://www.whatwg.org/specs/web-apps/...
Keywords:
Depends on: 34030 34020 34192
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-19 19:01 PST by Daniel Cheng
Modified: 2010-04-01 23:24 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Cheng 2010-01-19 19:01:56 PST
I'm currently working on this. According to the HTML5 draft, copy/cut/paste should dispatch the appropriate drag/drop events.

Roadmap:
1. Update WebCore/platform/win/ClipboardWin.cpp to support using the system clipboard as a data source. This work will /not/ reuse the general Pasteboard class. It seems easier to directly manipulate the system clipboard, since we already have an IDataObject, and we can use ::OleSetClipboard to drop it on the clipboard.
2. Update WebCore/editing/Editor.cpp to dispatch the appropriate drag and drop events for paste. At this point, copying and pasting a file from Explorer to WebKit should have the same behavior as dragging and dropping a file from Explorer to WebKit.
3. Update WebCore/editing/Editor.cpp to dispatch the appropriate drag and drop events for copy/cut.
4. Update WebCore/platform/win/ClipboardWin.cpp to allow event.dataTransfer.setData() with arbitrary types*.
5. Update the Mac clipboard implementation under WebCore/platform/ClipboardMac* to have the same functionality as the Windows equivalent.

* arbitrary types in Windows are actually quite limited.

New clipboard formats can be registered by calling ::RegisterClipboardFormat; however, there are a few problems with this approach.
- ::RegisterClipboardFormat() can only register up to 16,383 new unique formats. It will start failing once the max number of registrations is hit. There is no way to unregister short of a reboot. Furthermore, registering all clipboard formats results in random system failures elsewhere (many applications will fail to initialize)
- If we limit how many times WebKit can call ::RegisterClipboardFormat(), a malicious webpage can easily break the event.dataTransfer.setData() interface for every other webpage that loads in WebKit.

My current plan is to update the Clipboard class in Windows by doing the following:
All drag-drop/copy-paste operations will support some "standard" set of clipboard formats. What this list of formats should include is TBD, but things like the following should probably be included: application/rtf, text/rtf, text/html, image/jpeg, image/png, image/gif, text/plain, text/uri-list, etc.
- Copy and paste and external drag and drops to/from WebKit will only support the "standard" set of clipboard formats.
- Internal drag and drops in WebKit will use CF_PRIVATEFIRST - CF_PRIVATELAST. This allows 256 additional types of a webpage's choice to be used *per* event.dataTransfer. This isn't a great solution, but it does prevent the self DoS issue that using ::RegisterClipboardFormat() would cause.
Comment 1 Daniel Cheng 2010-04-01 23:24:44 PDT
This functionality has been removed from HTML5.