[Android] Removes delay when a tab is dragged with a mouse

[Android] Removes delay when a tab is dragged with a mouse

BUG=472318
Committed: https://crrev.com/9b18b59bac17d8c837010d941e38edc5a0798658
Cr-Commit-Position: refs/heads/master@{#340392}

[varkha, 2015-07-24 18:41:07]

varkha@chromium.org changed reviewers:
+ yfriedman@chromium.org

[varkha, 2015-07-24 18:41:08]

Yaron, can you please take a look? This may be very naive so take it with a
grain of salt it deserves. I am not even sure this should be done in this layer.
Also can you point me to a test for tab dragging or something close enough?

Thanks!

[varkha, 2015-07-24 19:01:51]

Yes, this was quite early I'm afraid. I think it needs to still send onDown and
deal with the cases where it needs to do something other than initiate drags
such as with clicking the [x] button and probably more. Still any insights would
be welcome.

[varkha, 2015-07-24 19:58:44]

New patch set works better but there are probably still pitfalls and I'm not
sure if there is a more elegant way to pass down the event source marker.

[varkha, 2015-07-24 20:27:35]

The CQ bit was checked by varkha@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-07-24 20:28:19]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1261443002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1261443002/20001

[Yaron, 2015-07-24 20:30:10]

yfriedman@chromium.org changed reviewers:
+ dtrainor@chromium.org
- yfriedman@chromium.org

[Yaron, 2015-07-24 20:30:11]

sorry, but I'm not really the best reviewer for this. I think dtrainor would be
a good reviewer or can redirect more intelligently

[commit-bot: I haz the power, 2015-07-24 21:34:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-24 21:34:55]

Dry run: This issue passed the CQ dry run.

[David Trainor- moved to gerrit, 2015-07-24 22:18:44]

lgtm

[varkha, 2015-07-25 01:01:08]

The CQ bit was checked by varkha@chromium.org

[varkha, 2015-07-25 01:01:09]

The patchset sent to the CQ was uploaded after l-g-t-m from
dtrainor@chromium.org
Link to the patchset: https://codereview.chromium.org/1261443002/#ps40001
(title: "[Android] Removes delay when a tab is dragged with a mouse (document
new parameters)")

[commit-bot: I haz the power, 2015-07-25 01:01:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1261443002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1261443002/40001

[commit-bot: I haz the power, 2015-07-25 01:45:55]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-07-25 01:46:48]

Patchset 3 (id:??) landed as
https://crrev.com/9b18b59bac17d8c837010d941e38edc5a0798658
Cr-Commit-Position: refs/heads/master@{#340392}

[David Trainor- moved to gerrit, 2015-07-29 17:26:08]

On 2015/07/25 01:46:48, commit-bot: I haz the power wrote:
> Patchset 3 (id:??) landed as
> https://crrev.com/9b18b59bac17d8c837010d941e38edc5a0798658
> Cr-Commit-Position: refs/heads/master@{#340392}

I just realized, does this break for situations where there are more strips in
the tab strip than can fit?  This removes the ability to scroll the tab strip
with a mouse.

[varkha, 2015-07-29 17:50:05]

On 2015/07/29 17:26:08, David Trainor wrote:
> On 2015/07/25 01:46:48, commit-bot: I haz the power wrote:
> > Patchset 3 (id:??) landed as
> > https://crrev.com/9b18b59bac17d8c837010d941e38edc5a0798658
> > Cr-Commit-Position: refs/heads/master@{#340392}
> 
> I just realized, does this break for situations where there are more strips in
> the tab strip than can fit?  This removes the ability to scroll the tab strip
> with a mouse.

Yes, good catch, thanks! Do you have a strong opinion on what should happen in
this case?
I was thinking a simplest thing we could do is to let the reordering start only
if
a currently active tab is touched down. Presumably it is less critical to
activate
and drag a tab in the same motion. If a tab is not active it will need to get
activated first which will force the tabstrip stacker to expose the tab.
This would allow stacker to be activated by dragging inactive tabs with a mouse.
Do you think this is worth an exeriment?

[varkha, 2015-07-29 18:15:04]

Another approach could be to check visible percentage of the dragged tab and not
engage reorder mode if the tab is not fully visible. I've tried this and it
seems to work. I will send a CL to take a look at.

[varkha, 2015-07-29 18:23:03]

See https://chromiumcodereview.appspot.com/1259823003/.