[Webkit-unassigned] [Bug 33877] New: HTML5: copy and paste should dispatch drag and drop events

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33877

           Summary: HTML5: copy and paste should dispatch drag and drop
                    events
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
               URL: http://www.whatwg.org/specs/web-apps/current-work/mult
                    ipage/dnd.html#copy-and-paste
        OS/Version: Windows Vista
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Platform
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dcheng at google.com
                CC: dimich at chromium.org, levin at chromium.org,
                    jianli at chromium.org


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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.