diff options
author | afakhry <afakhry@chromium.org> | 2015-12-08 13:59:42 -0800 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2015-12-08 22:01:23 +0000 |
commit | 66e589565dcb38ff95d27a2a91308308f19296ff (patch) | |
tree | e85bed3d43043258e0a89b067957731e49af05ce /ash | |
parent | a38bdd6dea99577c387e2849e85459396e8964aa (diff) | |
download | chromium_src-66e589565dcb38ff95d27a2a91308308f19296ff.zip chromium_src-66e589565dcb38ff95d27a2a91308308f19296ff.tar.gz chromium_src-66e589565dcb38ff95d27a2a91308308f19296ff.tar.bz2 |
Fix getting stuck with a modal background when a tab produces a modal dialog while drag is in progress
When a tab produces a modal dialog while it's being dragged (out into its own
browser frame), the newly created dialog will cause a capture loss, resulting
in reverting the drag. Reverting the drag will then destroy the browser frame
that owns the modal dialog, and the end result will be no modal dialog, and the
modal background is still there.
We simply complete the drag as a result of capture change. This is the behavior
in desktop linux.
BUG=558201
TEST=ash_unittests --gtest_filter=ToplevelWindowEventHandlerTest.GestureDragCaptureLoss
Review URL: https://codereview.chromium.org/1492713002
Cr-Commit-Position: refs/heads/master@{#363808}
Diffstat (limited to 'ash')
-rw-r--r-- | ash/wm/toplevel_window_event_handler.cc | 8 | ||||
-rw-r--r-- | ash/wm/toplevel_window_event_handler_unittest.cc | 4 |
2 files changed, 8 insertions, 4 deletions
diff --git a/ash/wm/toplevel_window_event_handler.cc b/ash/wm/toplevel_window_event_handler.cc index ecb4b3b..1b7ae90 100644 --- a/ash/wm/toplevel_window_event_handler.cc +++ b/ash/wm/toplevel_window_event_handler.cc @@ -582,8 +582,12 @@ void ToplevelWindowEventHandler::HandleMouseExited( } void ToplevelWindowEventHandler::HandleCaptureLost(ui::LocatedEvent* event) { - if (event->phase() == ui::EP_PRETARGET) - CompleteDrag(DRAG_REVERT); + if (event->phase() == ui::EP_PRETARGET) { + // We complete the drag instead of reverting it, as reverting it will result + // in a weird behavior when a dragged tab produces a modal dialog while the + // drag is in progress. crbug.com/558201. + CompleteDrag(DRAG_COMPLETE); + } } void ToplevelWindowEventHandler::SetWindowStateTypeFromGesture( diff --git a/ash/wm/toplevel_window_event_handler_unittest.cc b/ash/wm/toplevel_window_event_handler_unittest.cc index bec3eae..c2d708f 100644 --- a/ash/wm/toplevel_window_event_handler_unittest.cc +++ b/ash/wm/toplevel_window_event_handler_unittest.cc @@ -736,7 +736,7 @@ void CheckHasCaptureAndReleaseCapture(aura::Window* window) { } // namespace -// Test that releasing capture cancels an in-progress gesture drag. +// Test that releasing capture completes an in-progress gesture drag. TEST_F(ToplevelWindowEventHandlerTest, GestureDragCaptureLoss) { scoped_ptr<aura::Window> window(CreateWindow(HTNOWHERE)); ui::test::EventGenerator generator(Shell::GetPrimaryRootWindow(), @@ -747,7 +747,7 @@ TEST_F(ToplevelWindowEventHandlerTest, GestureDragCaptureLoss) { base::ThreadTaskRunnerHandle::Get()->PostTask( FROM_HERE, base::Bind(&CheckHasCaptureAndReleaseCapture, base::Unretained(window.get()))); - EXPECT_EQ(aura::client::MOVE_CANCELED, + EXPECT_EQ(aura::client::MOVE_SUCCESSFUL, move_client->RunMoveLoop(window.get(), gfx::Vector2d(), aura::client::WINDOW_MOVE_SOURCE_TOUCH)); } |