Tab cannot be dragged to a new target when using Alt+Tab |
|||||
Issue descriptionVersion: 55.0.2883.29 OS: Chrome OS What steps will reproduce the problem? (1) Drag a tab out of a Chrome window (don't release). (2) Alt+Tab to another window to make that window a target. (3) Drop the dragged tab into the new target. What is the expected output? The tab can be dropped into a new window What do you see instead? Capture is released earlier and the dragged tab becomes its own window. This is a recent Chrome OS - specific regression and describes a behavior that worked as late as in M-53. There is a more general bug 89537 but it would make sense to address this regression separately.
,
Nov 7 2016
what makes you think that? If it is broken on Windows, it's probably for a different reason.
,
Nov 7 2016
Just tried it recently with Win10. Could be indeed for a different reason.
,
Nov 9 2016
Is it a regression on Windows? If it's broken on Windows and has been for a while then I don't think it's a priority to fix this for 56 on cros.
,
Dec 7 2016
,
Jan 19 2017
,
Jan 20 2017
This doesn't work on windows and likely hasn't for a long time (if ever).
,
Jan 20 2017
it does work on metacity fwiw. I'm working on this, the difficulty is that our current behavior is designed to fix/work around 3 different bugs (around mouse clicks, screenshotting and tab dragging), so it's hard to fix this without regressing those.
,
Jan 20 2017
In case anyone is interested: https://codereview.chromium.org/2642273002/
,
Jan 24 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2080dad23aec7f5225154092b527acc4737f261c commit 2080dad23aec7f5225154092b527acc4737f261c Author: estade <estade@chromium.org> Date: Tue Jan 24 23:01:02 2017 CrOS - Make it possible to Alt+Tab while dragging a tab without interfering with the drag and drop operation. The Alt+Tab UI no longer does a mouse capture, and instead relies on event filters. BUG= 660945 Review-Url: https://codereview.chromium.org/2642273002 Cr-Commit-Position: refs/heads/master@{#445851} [modify] https://crrev.com/2080dad23aec7f5225154092b527acc4737f261c/ash/common/wm/window_cycle_list.cc [modify] https://crrev.com/2080dad23aec7f5225154092b527acc4737f261c/ash/wm/window_cycle_controller_unittest.cc [modify] https://crrev.com/2080dad23aec7f5225154092b527acc4737f261c/ash/wm/window_cycle_event_filter_aura.cc [modify] https://crrev.com/2080dad23aec7f5225154092b527acc4737f261c/ash/wm/window_cycle_event_filter_aura.h
,
Jan 25 2017
,
Jan 25 2017
The CL in #10 landed as 445851 which is after the M-57 branch, updating milestone accordingly. Evan, I assume you didn't want to merge back to 57?
,
Jan 25 2017
Not really a regression or bug fix, more of an improvement, so no, no merge required.
,
Jan 25 2017
I think it used to work in M-53 and earlier, at least on Chrome OS (and we are still early enough in M-57 to have merging this a possibility). But I also think it would be good to fix bug 685247 first.
,
Jan 26 2017
I remain unconvinced it's a good idea to merge. It's a minor improvement, it has a high chance of causing as-yet-unknown regressions, and I would not classify it as ReleaseBlock-Anything.
,
Jan 30 2017
I agree with #15, let's keep m-58 as the target for this.
,
Mar 21 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by varkha@chromium.org
, Nov 7 2016