Issue 841495 has been merged into this issue.

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

commit 602d2720f0c353b05c3f6615b3e78ea1bd5d7255
Author: Mark Cogan <marq@google.com>
Date: Tue Jul 17 09:19:11 2018

[iOS] Merge tab grid transitions with tab views.

This CL updates the tab grid transitions to cleanly match the presented tab views.

The basic abstraction for this transition is the GridToTabTransitionView protocol which defines a set of 'cell' and 'tab' views, and methods to lay them out. The general idea is that a view conforming to this protocol can either be in 'cell' mode (where it exactly matches a tab grid cell), or in 'tab' mode (where it exactly matches an open tab).

Most of the work is done by the GridTransitionCell subclass of GridCell, which positions and scales the "tab" and "cell" views it is supplied with so they animate smoothly. All of this positioning/scaling logic is internal to that class and nothing else depends on it.

Providing the transition cell with the tab views is handled in the transition animator, mostly leveraging the content area layout guide. This doesn't require any direct integration with the tab view (that is, the BVC) beyond that layout guide.

Approaches I abandoned:

- letting -layoutSubviews position the tab/grid views. The problem with this approach (which is much cleaner from an API perspective) is that the timing of the layout passes is unpredictable, it it resulted in changes being made that weren't fully animated (for example, subviews would be scaled and positioned without animation, and then the superview would scale with an animation).

- using layout constraints for GridTransitionCell's tab views. This is probably the correct thing to do long-term; mostly this was a decision made under time constraints, but since ultimately animating constraint changes depends on -layoutSubviews being called at the right times, I did have some concerns given the difficulties described above. It's unfortunate that grid_cell.mm is mixing constraint- and frame-based layout, but it is confined to that single file.

Bug:  851460 ,  850507 ,  862343 
Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: If6d55f14aa05e705143547b61773fdb34796ad2d
Reviewed-on: https://chromium-review.googlesource.com/1136647
Commit-Queue: Mark Cogan <marq@chromium.org>
Reviewed-by: Gauthier Ambard <gambard@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575590}
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/grid/grid_cell.mm
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/tab_grid_view_controller.mm
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/transitions/grid_to_tab_transition_view.h
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/transitions/grid_to_visible_tab_animator.mm
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/transitions/grid_transition_animation.mm
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/transitions/grid_transition_layout.h
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/transitions/grid_transition_layout.mm
[modify] https://crrev.com/602d2720f0c353b05c3f6615b3e78ea1bd5d7255/ios/chrome/browser/ui/tab_grid/transitions/tab_to_grid_animator.mm

 Issue 850112  has been merged into this issue.