Get rid of chrome dependencies from tab_contents_drag_win.cc. After this I'll move it to content\br…

chrome/browser/ui/views/tab_contents/tab_contents_drag_win.h

Index: chrome/browser/ui/views/tab_contents/tab_contents_drag_win.h
===================================================================
--- chrome/browser/ui/views/tab_contents/tab_contents_drag_win.h	(revision 124607)
+++ chrome/browser/ui/views/tab_contents/tab_contents_drag_win.h	(working copy)
@@ -6,19 +6,25 @@
 #define CHROME_BROWSER_UI_VIEWS_TAB_CONTENTS_TAB_CONTENTS_DRAG_WIN_H_
 #pragma once
 
+#include "base/callback.h"
 #include "base/memory/ref_counted.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/threading/platform_thread.h"
 #include "third_party/WebKit/Source/WebKit/chromium/public/WebDragOperation.h"
 #include "third_party/skia/include/core/SkBitmap.h"
 #include "ui/base/dragdrop/os_exchange_data_provider_win.h"
+#include "ui/gfx/native_widget_types.h"
 #include "ui/gfx/point.h"
 
 class DragDropThread;
-class NativeTabContentsViewWin;
+class WebDragDest;
 class WebDragSource;
 struct WebDropData;
 
+namespace content {
+class WebContents;
+}
+
 // Windows-specific drag-and-drop handling in WebContentsView.
 // If we are dragging a virtual file out of the browser, we use a background
 // thread to do the drag-and-drop because we do not want to run nested
@@ -28,7 +34,10 @@
     : public ui::DataObjectImpl::Observer,
       public base::RefCountedThreadSafe<TabContentsDragWin> {
  public:
-  explicit TabContentsDragWin(NativeTabContentsViewWin* view);
+  TabContentsDragWin(gfx::NativeWindow source_wnd,
+                     content::WebContents* web_contents,
+                     WebDragDest* drag_dest,
+                     const base::Callback<void()>& drag_end_callback);
   virtual ~TabContentsDragWin();
 
   // Called on UI thread.
@@ -76,8 +85,9 @@
 
   // All the member variables below are accessed on UI thread.
 
-  // Keep track of the TabContentsViewViews it is associated with.
-  NativeTabContentsViewWin* view_;
+  gfx::NativeWindow source_wnd_;

[dcheng, 2012/03/02 18:54:47]

Seems a little unfortunate that we turn 1 pointer into 3 closely related
pointers. Would it make sense to put a thin content interface around this so we
carry these pointers around together?

[jam, 2012/03/02 18:56:37]

I prefer not adding a new interface just to carry three pointers. the more files
we have in content\public, the more daunting it seems to newcomers.

[dcheng, 2012/03/02 19:04:17]

OK, I'm not too thrilled with this part of the change but I won't block it based
on that.

[dcheng, 2012/03/02 19:04:17]

Minor nit: window_ instead of wnd_. Similar for other places that use wnd.

[jam, 2012/03/02 19:09:59]

Done.

[jam, 2012/03/02 19:09:59]

I think this may be a personal style difference :) I think classes that take 3
or 4 arguments is quite normal. an interface would be useful if this value can
change later and so a cache won't work. but in this situation, it would make the
code less readable imo.

+  content::WebContents* web_contents_;
+  WebDragDest* drag_dest_;
 
   // |drag_source_| is our callback interface passed to the system when we
   // want to initiate a drag and drop operation.  We use it to tell if a
@@ -94,6 +104,8 @@
   // Keep track of the old suspended state of the drop target.
   bool old_drop_target_suspended_state_;
 
+  base::Callback<void()> drag_end_callback_;
+
   DISALLOW_COPY_AND_ASSIGN(TabContentsDragWin);
 };