Ed/Mark, please triage and apply the appropriate labels.

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

commit 4a8424da850040109a5fc6b3ca0988b95e364c5e
Author: Rohit Rao <rohitrao@chromium.org>
Date: Wed Apr 25 14:36:08 2018

[ios] Fixes TabUsageRecorderTest when the UIRefresh flag is enabled.

Updates the egtest utils to support the new TabGrid.  Adds a temporary
workaround for a TabGrid bug.

BUG=818732, 836312 

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I66efdbcfce9318a7245463cb2cf7d4f0592ed5de
Reviewed-on: https://chromium-review.googlesource.com/1026411
Commit-Queue: Rohit Rao <rohitrao@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553547}
[modify] https://crrev.com/4a8424da850040109a5fc6b3ca0988b95e364c5e/ios/chrome/browser/metrics/BUILD.gn
[modify] https://crrev.com/4a8424da850040109a5fc6b3ca0988b95e364c5e/ios/chrome/browser/metrics/tab_usage_recorder_egtest.mm
[modify] https://crrev.com/4a8424da850040109a5fc6b3ca0988b95e364c5e/ios/chrome/browser/metrics/tab_usage_recorder_test_util.h
[modify] https://crrev.com/4a8424da850040109a5fc6b3ca0988b95e364c5e/ios/chrome/browser/metrics/tab_usage_recorder_test_util.mm

edchin@ could you PTAL?

I believe the correct behavior for Done is to return to the same tab from which you entered the tab grid. 

Think about a user who enters the tab grid from a tab and swipes to the recent tabs panel, then changes their mind and wants to return to their tab. Shouldn't the Done button be available in the third panel? Under the behavior that I describe, the done button is available since it returns you to the tab from which you entered.

+mardini

 Issue 848634  has been merged into this issue.

I agree that the correct behavior for Done is to return to the same tab from which you entered the tab grid. I think a certain level of intentionality is needed to foreground a given tab (especially if it is an incognito one). 

But in light of that, we should just have only one selector ring around the active tab's thumbnails across all spaces. i.e. incognito and regular. That is the tab the user would go back to when they click "Done". 

So if the user is in a regular tab, they enter tab grid in regular space, they swipe to incognito panel, there shouldn't be a a selector ring around any incognito tabs thumbnails. 

The inverse is also true. User is in incognito tab, enters tab grid incognito space, swipe to regular tabs panel, there shouldn't be a selector ring around any regular tabs thumbnails.

Issue 851925 has been merged into this issue.

I disagree with hiding the selector ring for the other panel -- that visual indicator provides useful context when switching back and forth between panels.  I often have a ton of tabs with similar-looking snapshots, and without the selector ring, I'm not sure I would know which tab I was on last.

(As a strawman, imagine if you had 100 tabs in each panel, but when switching panels, we always insisted on throwing away your current state and scrolling you back up to Tab #0.  I would find that unusable.)

The existing phone app does the opposite -- if you switch panels, then exit the tab switcher, we show the tab for the panel that is currently visible.

Fair point but I didn’t talk about scrolling back up to tab#0. I was just talking about the selector ring bring one across both spaces to convey the meaning that there is one active tab not two. I’m ok keeping two selector rings if you think this helps. I find it a bit inconsistent though.
Pink: what do you think? 

I think we should keep the selector rings, and Done should switch to the mode/panel currently visible on the screen. If "recent tabs" is the current panel, we go back to the mode the user was in when they entered. 

Logic goes like this:
- If i'm looking at something, that's where I end up when I press done.
- If i'm looking at recent tabs, then ending up where I began is least surprising.

This will make it easy to switch back and forth between regular and incognito, as well as being very obvious to the user what's happening. This also matches the behavior of the current app. 

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

commit 07981acba6d2e36c9826e46699bcf6c5505ea73a
Author: edchin <edchin@chromium.org>
Date: Thu Jun 21 07:06:33 2018

[ios] Modify done button behavior in tab grid

Updating the done button behavior to follow these rules:
- If I'm looking at something, that's where I end up when I press done.
- If I'm looking at recent tabs, then ending up where I began is least
surprising.

Bug:  836312 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Idcac4af078aa0e8ca658aec8601db212b21585c0
Reviewed-on: https://chromium-review.googlesource.com/1108749
Reviewed-by: edchin <edchin@chromium.org>
Reviewed-by: Sergio Collazos <sczs@chromium.org>
Commit-Queue: edchin <edchin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569178}
[modify] https://crrev.com/07981acba6d2e36c9826e46699bcf6c5505ea73a/ios/chrome/browser/ui/tab_grid/tab_grid_view_controller.mm

Verified on iPhone 6+ iOS 11.4, iPhone 7+ iOS 10.3.3 , iPad Pro 12'9 iOS 11.4.1 on  69.0.3497.50 Beta as per #0