summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorafakhry <afakhry@chromium.org>2015-12-08 13:59:42 -0800
committerCommit bot <commit-bot@chromium.org>2015-12-08 22:01:23 +0000
commit66e589565dcb38ff95d27a2a91308308f19296ff (patch)
treee85bed3d43043258e0a89b067957731e49af05ce
parenta38bdd6dea99577c387e2849e85459396e8964aa (diff)
downloadchromium_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}
-rw-r--r--ash/wm/toplevel_window_event_handler.cc8
-rw-r--r--ash/wm/toplevel_window_event_handler_unittest.cc4
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));
}