[Webkit-unassigned] [Bug 36482] Regression(r55766): [Chromium] chromiumDataObject.hasData() reports true for an empty clipboard

[bugzilla-daemon at webkit.org]

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





--- Comment #7 from Tony Chang (Google) <tony at chromium.org>  2010-03-24 00:36:13 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > I guess I'm a bit confused.  There are layout tests that test dragging URLs in
> > a page (e.g., fast/events/drag-in-frames.html).  Do they go through this code
> > path?
> 
> AFAICT the only place where it is called is in the copying code within
> webdropdata.cc I mentioned. I.e., WebDropTarget::OnDragEnter creates a
> WebDropData from the Windows clipboard and forwards it via IPC. On the other
> side, in RenderView::OnDragTargetDragEnter(), it is immediately converted to a
> WebDragData object, and during that conversion setURL(url) is called.

Aha, found it.  ChromiumClipboard is a friend class of ChromiumDataObject and
it sets url directly in a lot of places (declareAndWriteDragImage, writeURL,
etc).  I guess they should no longer be friends?  That causes this check to be
missed most of the time.

> > I agree that we should sanitize the data.  Isn't that what the if statement
> > after the assert does?  It seems like we shouldn't crash in debug because the
> > user dragged the recycling bin onto chrome.
> 
> When dragging the recycle bin, newURL.isEmpty() is true, so the ASSERT doesn't
> trigger. (It's for this case that I made the change after all. ;) )

Ah I see.  Sorry I misunderstood the ASSERT, it seems fine.

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