WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
42121
[chromium] Add new WebClipboard method for setting generic data in copy/cut handlers.
https://bugs.webkit.org/show_bug.cgi?id=42121
Summary
[chromium] Add new WebClipboard method for setting generic data in copy/cut h...
Daniel Cheng
Reported
2010-07-12 17:40:14 PDT
Since it doesn't look like
https://bugs.webkit.org/show_bug.cgi?id=40515
is going anywhere, work around it in M6 by creating another setter function. It'd still be nice to take the changes in
https://bugs.webkit.org/show_bug.cgi?id=40515
and get rid of this new function in the embedding layer, but that's not going to happen in M6.
Attachments
Patch
(1.72 KB, patch)
2010-07-12 17:43 PDT
,
Daniel Cheng
fishd
: review-
Details
Formatted Diff
Diff
Patch
(2.35 KB, patch)
2010-07-13 14:53 PDT
,
Daniel Cheng
no flags
Details
Formatted Diff
Diff
Patch
(4.38 KB, patch)
2010-08-26 15:32 PDT
,
Daniel Cheng
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Daniel Cheng
Comment 1
2010-07-12 17:43:27 PDT
Created
attachment 61301
[details]
Patch
Darin Fisher (:fishd, Google)
Comment 2
2010-07-12 22:41:01 PDT
Comment on
attachment 61301
[details]
Patch you need to update the ChangeLog file. it'd be helpful also if i could see how this new function will be used.
Daniel Cheng
Comment 3
2010-07-13 14:53:51 PDT
Created
attachment 61419
[details]
Patch Sorry, forgot to commit the changes for the ChangeLog. ClipboardChromium::setData (or ChromiumDataObject) will call ChromiumBridge::clipboard()->writeDataFlavor() directly when setting data for a copy/cut. As mentioned in
bug 40515
, it'd be nice if we had the equivalent of startDrag() for copy and cut, but I don't think that feature is going to make M6.
Tony Chang
Comment 4
2010-08-02 13:48:02 PDT
I think this would be easier to review if you had a chromium side change demonstrating how it's used.
Eric Seidel (no email)
Comment 5
2010-08-06 13:49:44 PDT
Comment on
attachment 61419
[details]
Patch r- based on tony and darin's comments above.
Daniel Cheng
Comment 6
2010-08-23 16:21:57 PDT
(In reply to
comment #4
)
> I think this would be easier to review if you had a chromium side change demonstrating how it's used.
I'll try to post a patch for that this evening. I'm trying to separate my patches from each other right now, and it's a rather painful process. It's needed because drags and copies/cuts aren't written back to the system data object the same way. For drags: The drag controller starts a drag. The DOM receives a dragstart event and populates event.dataTransfer. The drag controller calls DragClient::startDrag(), which passes all the data that was set in event.dataTransfer to the Chromium side. For copy/cut: The editor clears the pasteboard before it does anything. Then a copy/cut event is dispatched to the DOM, and for each call to event.dataTransfer.setData(), data is immediately written back to the system pasteboard. There is no analogous version of DragClient::startDrag() for pasteboard operations. I wanted to add this, but haven't done so since I didn't receive feedback from Darin Adler. Since we must write back immediately, and the existing APIs are not rich enough, I added a new interface.
Daniel Cheng
Comment 7
2010-08-26 15:32:23 PDT
Created
attachment 65628
[details]
Patch
Tony Chang
Comment 8
2010-08-26 16:19:39 PDT
Comment on
attachment 65628
[details]
Patch I see, we're not using writeData yet (it looks like a stub on the chromium side). In that case, this seems fine. Don't forget to update webclipboard_impl.* on the Chromium side too.
WebKit Commit Bot
Comment 9
2010-08-27 19:25:44 PDT
Comment on
attachment 65628
[details]
Patch Clearing flags on attachment: 65628 Committed
r66293
: <
http://trac.webkit.org/changeset/66293
>
WebKit Commit Bot
Comment 10
2010-08-27 19:25:50 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug