Cancel drag upon screen lock

Cancel drag upon screen lock.
I believe cancel upon capture lost is necessary regardless.

BUG=175486
TEST=covered by tests, manually on lock screen.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=190534

[varunjain, 2013-03-25 18:04:23]

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
File ash/drag_drop/drag_drop_controller.cc (right):

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
ash/drag_drop/drag_drop_controller.cc:82: class DragDropWindowDelegate : public
aura::WindowDelegate {
nit: rename to DragDropTrackerDelegate or DragDropTrackerWindowDelegate

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
ash/drag_drop/drag_drop_controller.cc:328: // Ignore if the drag window is
already deleted. This happens when
Can we handle this case in DragDropWindowDelegate::OnWindowDestrying?

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
File ash/drag_drop/drag_drop_controller_unittest.cc (right):

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
ash/drag_drop/drag_drop_controller_unittest.cc:805:
TEST_F(DragDropControllerTest, MAYBE_CaptureLostCancelsDragDrop) {
I am a bit concerned that now that we have a non-NULL delegate,
Window::GetWindowForPoint() for the DragDropTracker::capture_window_ is no
longer NULL. This is ok I think because the capture_window_ size is 0x0 so it
would not hittest. Can you add another test case that just ensures that the
capture_window_ size is 0x0?

[oshima, 2013-03-25 20:41:10]

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
File ash/drag_drop/drag_drop_controller.cc (right):

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
ash/drag_drop/drag_drop_controller.cc:82: class DragDropWindowDelegate : public
aura::WindowDelegate {
On 2013/03/25 18:04:23, varunjain wrote:
> nit: rename to DragDropTrackerDelegate or DragDropTrackerWindowDelegate

Done.

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
ash/drag_drop/drag_drop_controller.cc:328: // Ignore if the drag window is
already deleted. This happens when
On 2013/03/25 18:04:23, varunjain wrote:
> Can we handle this case in DragDropWindowDelegate::OnWindowDestrying?

Checking if drag&drop is in progress in OnCaptureLost seems to work.
How does this look to you?

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
File ash/drag_drop/drag_drop_controller_unittest.cc (right):

https://codereview.chromium.org/13041002/diff/8008/ash/drag_drop/drag_drop_co...
ash/drag_drop/drag_drop_controller_unittest.cc:805:
TEST_F(DragDropControllerTest, MAYBE_CaptureLostCancelsDragDrop) {
On 2013/03/25 18:04:23, varunjain wrote:
> I am a bit concerned that now that we have a non-NULL delegate,
> Window::GetWindowForPoint() for the DragDropTracker::capture_window_ is no
> longer NULL. This is ok I think because the capture_window_ size is 0x0 so it
> would not hittest. Can you add another test case that just ensures that the
> capture_window_ size is 0x0?

I added a few more checks here as the rest of it is identical.
I put them in here because the rest of the code is identical but
am happy to move it to separate test. Let me know.

Additionally, I changed to create empty HitTestMask to make sure it won't handle
any mouse events.

[varunjain, 2013-03-25 21:49:05]

lgtm

[commit-bot: I haz the power, 2013-03-25 22:01:35]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/oshima@chromium.org/13041002/13001

[oshima, 2013-03-26 00:55:21]

Committed patchset #3 manually as r190534 (presubmit successful).