Bug 81079 - REGRESSION(r107844): Clipboard API only remembers most recent data set on clipboard
Summary: REGRESSION(r107844): Clipboard API only remembers most recent data set on cli...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2012-03-13 22:47 PDT by Alan Tam
Modified: 2012-03-15 13:23 PDT (History)
1 user (show)

See Also:


Attachments
test case (1.14 KB, text/html)
2012-03-13 22:47 PDT, Alan Tam
no flags Details
Patch with layout test (16.50 KB, patch)
2012-03-15 12:08 PDT, Brady Eidson
sam: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Tam 2012-03-13 22:47:46 PDT
Created attachment 131790 [details]
test case

Open the attached html, and hit Cmd-C and then Cmd-V.
Expected: Hello and World are shown. Actual: Only World is shown.
The html calls evt.clipboardData.setData() twice on two mime types, and "Clipboard Viewer" reveals that the latter overwrites the former.

WebKit trunk has regressed as follows:
* r107802: works
* r107978 to r109142: the left output shows undefined
* r109209 onwards: the left output shows empty string
Comment 1 Alexey Proskuryakov 2012-03-14 10:33:51 PDT
<rdar://problem/11047262>
Comment 2 Brady Eidson 2012-03-15 09:24:47 PDT
The first breakage was caused by http://trac.webkit.org/changeset/107844

After that revision, the clipboard only remembers the most recent data set on it.

Further breakage was caused in http://trac.webkit.org/changeset/109176 which is what caused "undefined" to start returning empty/null
Comment 3 Brady Eidson 2012-03-15 09:25:14 PDT
(In reply to comment #2)
> The first breakage was caused by http://trac.webkit.org/changeset/107844
> 
> After that revision, the clipboard only remembers the most recent data set on it.
> 
> Further breakage was caused in http://trac.webkit.org/changeset/109176 which is what caused "undefined" to start returning empty/null

I'm working on the first break right now, I'll file a second bugzilla when it's time to work on the second break.
Comment 4 Brady Eidson 2012-03-15 09:42:38 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > The first breakage was caused by http://trac.webkit.org/changeset/107844
> > 
> > After that revision, the clipboard only remembers the most recent data set on it.
> > 
> > Further breakage was caused in http://trac.webkit.org/changeset/109176 which is what caused "undefined" to start returning empty/null
> 
> I'm working on the first break right now, I'll file a second bugzilla when it's time to work on the second break.

Nevermind, http://trac.webkit.org/changeset/109176 was an intentional change to match the spec.  Great!
Comment 5 Brady Eidson 2012-03-15 09:52:15 PDT
The key change was in ClipboardMac::setData.

Before r107844 ClipboardMac::setData used the NSPasteBoard API [NSPasteBoard addTypes:owner:] which takes an array of types to add, and adds them to the already existing pasteboard types.

In r107844 and later, ClipboardMac::setData does the following:
-Uses the PlatformStrategies method "setTypes" to pass off the new types to add.  Notice the method name is notably wrong.
-The WebKit Platform Strategies turn around and all PlatformPasteboard::setTypes().  Notice the method name is notably wrong.
-PlatformPasteboardMac::setTypes() uses the NSPasteBoard API  [NSPasteBoard declareTypes:owner:] which explicitly clears all previous contents and adds only the included types.
Comment 6 Brady Eidson 2012-03-15 12:08:51 PDT
Created attachment 132098 [details]
Patch with layout test
Comment 7 Brady Eidson 2012-03-15 13:23:57 PDT
http://trac.webkit.org/changeset/110880