Allow dragging and dropping of URLs to any portion of the toolbar view....

chrome/browser/ui/views/toolbar_view.cc

Index: chrome/browser/ui/views/toolbar_view.cc
===================================================================
--- chrome/browser/ui/views/toolbar_view.cc	(revision 74430)
+++ chrome/browser/ui/views/toolbar_view.cc	(working copy)
@@ -607,6 +607,20 @@
     canvas->FillRectInt(SK_ColorBLACK, 0, height() - 1, width(), 1);
 }
 
+bool ToolbarView::CanDrop(const ui::OSExchangeData& data) {
+  // To support loading URLs by dropping into the toolbar, we need to support
+  // dropping URLs and/or text.
+  return data.HasURL() || data.HasString();
+}
+
+int ToolbarView::OnDragUpdated(const views::DropTargetEvent& event) {
+  return ui::DragDropTypes::DRAG_COPY;

[sky, 2011/02/11 01:06:07]

I think you should allow move or link too. But, you shouldn't allow move if the
drag originated from the edit.

[Roger Tawa OOO till Jul 10th, 2011/02/11 15:20:17]

Changed to support either copy or link, just like edit.  However, I don't think
move makes sense for any drag source.

[sky, 2011/02/11 17:14:53]

Fair enough, but shouldn't we ignore the drop entirely if it's drop the edit?

[Roger Tawa OOO till Jul 10th, 2011/02/11 21:35:26]

If the drop is on the edit itself, it uses its own handler for the drop.  This
code path does not handle that case.

[sky, 2011/02/11 23:18:50]

If you drag the url from the omnibox it won't allow you to drop it on the
omnibox. But it seems like this change would end up showing the drop cursor when
you drag from the omnibox to the toolbar, but not do anything. We should be
consistent and either always allow the drop or always disallow the drop in such
a situation.

+}
+
+int ToolbarView::OnPerformDrop(const views::DropTargetEvent& event) {
+  return location_bar_->location_entry()->OnPerformDrop(event);
+}
+
 void ToolbarView::OnThemeChanged() {
   LoadImages();
 }