New issue
Advanced search Search tips

Issue 892517 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 19
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Let RevertDrag() handle the merge-back-to-source-window case

Project Member Reported by x...@chromium.org, Oct 5

Issue description

Chrome Version: (copy from chrome://version)
OS: Chrome

It's a comment from the CL review https://chromium-review.googlesource.com/c/chromium/src/+/1259468/. 

When a tab dragging process is ended, sometimes we need to merge the dragged window back into the source window. Currently we're setting the kIsDeferredTabDraggingTargetWindowKey property on the source window from ash side to inform chrome to do proper merge-back when drag ends.

We should consider to use RevertDrag() directly for this case. To do this, ClearTabDraggingInfo() should be moved to a later point after CompleteDrag() or RevertDrag() is called. 

 
Project Member

Comment 1 by bugdroid1@chromium.org, Oct 19

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5da197d1ea992e51d810ffa1c67d7daca1f09cc0

commit 5da197d1ea992e51d810ffa1c67d7daca1f09cc0
Author: Xiaoqian Dai <xdai@chromium.org>
Date: Fri Oct 19 20:29:38 2018

Revert drag if the tab is not dragged far enough.

Let TabDragController::RevertDrag() to handle the case if the dragged
tab is not dragged far enough and needs to be merged back to its source
window's tabstrip.

This CL also moved the bounds update of source window to
SplitViewController::TabDraggedWindowObserver after the drag ends.

This CL also reverts the change in
https://chromium-review.googlesource.com/c/chromium/src/+/1266495 since
after this CL, the reason to split the one function
ClearTabDraggingInfo() into two functions no longer exists.

Bug:  892517 
Change-Id: I412efa82cbba8629d750859865e11ab21d020637
Reviewed-on: https://chromium-review.googlesource.com/c/1290269
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Commit-Queue: Xiaoqian Dai <xdai@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601280}
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/ash/wm/overview/window_grid.cc
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/ash/wm/splitview/split_view_controller.cc
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/ash/wm/splitview/split_view_controller_unittest.cc
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/ash/wm/tablet_mode/tablet_mode_browser_window_drag_delegate.cc
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/ash/wm/tablet_mode/tablet_mode_window_manager.cc
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/ash/wm/tablet_mode/tablet_mode_window_state.cc
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/ash/wm/tablet_mode/tablet_mode_window_state.h
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/chrome/browser/ui/views/tabs/tab_drag_controller.cc
[modify] https://crrev.com/5da197d1ea992e51d810ffa1c67d7daca1f09cc0/chrome/browser/ui/views/tabs/tab_drag_controller.h

Labels: -Pri-3 Merge-Request-71 Pri-2
Status: Fixed (was: Assigned)
As RevertDrag() guaranteed the dragged tab(s) merges back into its (their) original position, I think it's worthy a merge-back to M71. 
Project Member

Comment 3 by sheriffbot@chromium.org, Oct 20

Labels: -Merge-Request-71 Hotlist-Merge-Review Merge-Review-71
This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
This change impacts a number of areas.  Can you add context to verify all is working and low risk?  Thanks
Although this CL touched many files, it should be safe to merge back. 

The reason I requested a merge-back is this CL also fixed a merge-back behavior. Before this CL, if a tab is dragged out from a window, but is not dragged long enough (more than half of the screen height), the tab will be merged back into the window, but is always merged back to the first tab of the window. After this CL, the tab will be merged back to its original position of the window. 
Safe meaning it was tested?  Need to evaluate risk on the test results.  Thanks
I tested it on my device and also all unittests were passed. No tester has verified the issue yet.

Anyway, I don't have strong preference to merge it back. If you feel it's risky, I can just keep it in M72.
Labels: -Merge-Review-71 Merge-Rejected-71
Since it's a P2 let's push to M72, unless you have broad test coverage and consider low risk.  Declining the merge; feel free to re-request if this escalates.

Sign in to add a comment