WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
56193
Dragging image to desktop gives webloc instead of image file in WebKit2
https://bugs.webkit.org/show_bug.cgi?id=56193
Summary
Dragging image to desktop gives webloc instead of image file in WebKit2
Darin Adler
Reported
2011-03-11 07:51:24 PST
Dragging image to desktop gives webloc instead of image file in WebKit2
Attachments
Patch
(23.49 KB, patch)
2011-03-11 07:55 PST
,
Darin Adler
no flags
Details
Formatted Diff
Diff
Patch
(23.51 KB, patch)
2011-03-12 05:30 PST
,
Darin Adler
sam
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Darin Adler
Comment 1
2011-03-11 07:55:01 PST
Created
attachment 85477
[details]
Patch
Enrica Casucci
Comment 2
2011-03-11 12:03:19 PST
Comment on
attachment 85477
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=85477&action=review
The code looks good to me. It's a very clever way of solving the problem! I'm assuming you've verified that the rest of the image dragging works as before.
> Source/WebKit2/WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:99 > + // FIXME: Seems this mesage should be named StartDrag, not SetDragImage.
typo message. It was named after the AppKit API, but I agree that this actually starts the dragging.
> Source/WebKit2/WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:173 > +
It is a bit hard to follow, given the amount of changes, but I don't understand why you're writing all the data to the pasteboard without checking the types required. Could you please clarify?
Eric Seidel (no email)
Comment 3
2011-03-11 16:11:21 PST
Attachment 85477
[details]
did not build on mac: Build output:
http://queues.webkit.org/results/8144005
Darin Adler
Comment 4
2011-03-12 05:30:11 PST
Created
attachment 85589
[details]
Patch
Sam Weinig
Comment 5
2011-03-12 11:03:12 PST
Comment on
attachment 85589
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=85589&action=review
> Source/WebKit2/WebProcess/WebPage/WebPage.cpp:1519 > +#if PLATFORM(MAC) > + platformDragEnded(); > +#endif
In general, I like having calls like these without the #if, and have each platform just have a stubbed out implementation.
Darin Adler
Comment 6
2011-03-12 19:12:04 PST
Committed
r80948
: <
http://trac.webkit.org/changeset/80948
>
Darin Adler
Comment 7
2011-03-12 20:04:49 PST
(In reply to
comment #2
)
> (From update of
attachment 85477
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=85477&action=review
> > The code looks good to me. It's a very clever way of solving the problem! I'm assuming you've verified that the rest of the image dragging works as before.
I did some testing. Not sure I covered everything.
> > Source/WebKit2/WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:99 > > + // FIXME: Seems this mesage should be named StartDrag, not SetDragImage. > > typo message. It was named after the AppKit API, but I agree that this actually starts the dragging.
Oops, I missed your note and didn’t fix the typo. The AppKit API is named dragImage... not setDragImage, so I think our name is not really in the same spirit.
> > Source/WebKit2/WebProcess/WebCoreSupport/mac/WebDragClientMac.mm:173 > > It is a bit hard to follow, given the amount of changes, but I don't understand why you're writing all the data to the pasteboard without checking the types required. Could you please clarify?
The way the code works is that it puts the list of types in, and then checks each type. Since the code put the types in, there is no need for it to double check what it put in! Presumably the checks existed in the code we copied this from because there was some kind of separation of responsibilities of determining which types to include and putting the data on the pasteboard. But here I see no need for this checking.
Darin Adler
Comment 8
2011-03-12 20:09:53 PST
***
Bug 56224
has been marked as a duplicate of this bug. ***
Darin Adler
Comment 9
2011-03-12 20:10:34 PST
Oops, wrong 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