New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 817885 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug

Blocking:
issue 648314



Sign in to add a comment

Android tab switcher cleanup for multi-stack support

Project Member Reported by rlanday@chromium.org, Mar 1 2018

Issue description

In https://crbug.com/648314, I am updating the Android tab switcher to support more than two tab stacks. This bug is for tracking various cleanup work (e.g. fixing bugs and removing dead code) I'm doing in preparation for the main changes.

Bugs that will be fixed:

- Dragging a tab to discard "drops" the tab once your finger hits the other stack

- Swiping between tab stacks doesn't work properly in landscape mode

- Swiping between tab stacks doesn't work properly in RTL mode

- Quickly dragging a tab can result in odd behavior (e.g. starting to discard in a direction it shouldn't)
 
Project Member

Comment 2 by bugdroid1@chromium.org, Mar 1 2018

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

commit d8bcc8fcbc3bac609db86f0d7b2424b35e3f4397
Author: Ryan Landay <rlanday@chromium.org>
Date: Thu Mar 01 19:46:36 2018

Improve behavior on Android when dragging to close tab

Currently, if you're in the Android tab picker and you're dragging to close a
tab, but your finger hits the other stack, we treat this as if you immediately
lifted your finger once it hit the other stack. This feels kind of weird and
jarring.

This CL fixes the behavior so the tab keeps getting dragged until you actually
lift your finger.

Bug:  817885 
Change-Id: I5ea113d28dccfa33b29c33575f0b6e29f9dfb9ef
Reviewed-on: https://chromium-review.googlesource.com/935667
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540259}
[modify] https://crrev.com/d8bcc8fcbc3bac609db86f0d7b2424b35e3f4397/chrome/android/java/src/org/chromium/chrome/browser/compositor/layouts/phone/StackLayout.java

Project Member

Comment 3 by bugdroid1@chromium.org, Mar 2 2018

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

commit 107778ff9814b79db74e9ab6c12afd53009b728e
Author: Ryan Landay <rlanday@chromium.org>
Date: Fri Mar 02 22:14:37 2018

Rewrite StackLayout#computeInputMode()

The current implementation of StackLayout#computeInputMode() contains mysterious
thresholds, misnamed variables (distanceToDownSqr is the square of the distance
moved *in the current frame*, not the distance since touch down), and dubious
logic (comparisons between misnamed variables and mysterious thresholds). Most
importantly, when I add a third stack, with the current logic, quick horizontal
drags actually cause the stack in the middle to start animating a tab discard.

This CL rewrites the logic in computeInputMode() to be more clear about what's
actually going on, and fix the problem I'm running into with a third stack. Now,
right after a user starts moving their finger, we decide whether they're
performing a horizontal or vertical drag, and ignore all movement in the other
direction for as long as they have their finger down. This prohibits certain
drag operations that are currently possible (e.g. scrolling up in a tab stack,
then dragging horizontally to scroll over to another tab stack without lifting
your finger), but these are not clearly useful, and seem more trouble than
they're worth to support.

Bug:  817885 
Change-Id: I8959dffafb961de533d7d719c37a9b7c4ef0f333
Reviewed-on: https://chromium-review.googlesource.com/940188
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540657}
[modify] https://crrev.com/107778ff9814b79db74e9ab6c12afd53009b728e/chrome/android/java/src/org/chromium/chrome/browser/compositor/layouts/phone/StackLayout.java

Status: Fixed (was: Started)
Project Member

Comment 5 by bugdroid1@chromium.org, Mar 8 2018

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

commit 9e80803ff42fbc6a26b66fc4f9c6853b80e3b43d
Author: Ryan Landay <rlanday@chromium.org>
Date: Thu Mar 08 23:00:01 2018

Use @IntDef instead of enum for StackLayout#SwipeMode

It came up during review of
https://chromium-review.googlesource.com/c/chromium/src/+/940188 that this class
should be using @IntDefs instead of enums for efficiency reasons. This CL
changes SwipeMode from an enum to an @IntDef.

Bug:  817885 
Change-Id: Iaded46027fd3409c936ef48208464e363df1cab1
Reviewed-on: https://chromium-review.googlesource.com/944546
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541919}
[modify] https://crrev.com/9e80803ff42fbc6a26b66fc4f9c6853b80e3b43d/chrome/android/java/src/org/chromium/chrome/browser/compositor/layouts/phone/StackLayout.java

Sign in to add a comment