Add context to gfx::Screen calls in support of simultaneous desktop+ash

chrome/browser/ui/views/tabs/tab_drag_controller.cc

Index: chrome/browser/ui/views/tabs/tab_drag_controller.cc
diff --git a/chrome/browser/ui/views/tabs/tab_drag_controller.cc b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
index 86caeb454633555522266937e5ff2bd6c511f0e3..bbfc7fbb3e052c579fcdba7dd6c110dfb634f094 100644
--- a/chrome/browser/ui/views/tabs/tab_drag_controller.cc
+++ b/chrome/browser/ui/views/tabs/tab_drag_controller.cc
@@ -671,7 +671,9 @@ gfx::Point TabDragController::GetWindowCreatePoint(
 
   // If the cursor is outside the monitor area, move it inside. For example,
   // dropping a tab onto the task bar on Windows produces this situation.
-  gfx::Rect work_area = gfx::Screen::GetDisplayNearestPoint(origin).work_area();
+  gfx::Rect work_area = gfx::Screen::GetScreenFor(
+      source_tabstrip_->GetWidget()->GetNativeView())->
+          GetDisplayNearestPoint(origin).work_area();

[oshima, 2012/10/10 17:58:23]

Any reason this and next change are using different widgets?

[scottmg, 2012/10/10 19:04:47]

No, I'm just not familiar with code, so I wasn't clear on when particular
members are valid.

Looking at where GetWindowCreatePoint is called from pointed to source_tabstrip_
being valid at this point, whereas below,
GetAttachedBrowserWidget()/attached_tabstrip_ look to be valid. So, using a
different one in both places seemed the safest change.

   gfx::Point create_point(origin);
   if (!work_area.IsEmpty()) {
     if (create_point.x() < work_area.x())
@@ -1983,7 +1985,8 @@ gfx::Point TabDragController::GetCursorScreenPoint() {
     return touch_point;
   }
 #endif
-  return gfx::Screen::GetCursorScreenPoint();
+  return gfx::Screen::GetScreenFor(
+      GetAttachedBrowserWidget()->GetNativeView())->GetCursorScreenPoint();
 }
 
 gfx::Point TabDragController::GetWindowOffset(