commit fd28fb2cbf833f5442454373affceec76cbfc5ea
author Taylor Bergquist <tbergquist@chromium.org> Wed Feb 05 22:42:16 2025
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed Feb 05 22:42:16 2025
tree a63f4fa774e450f7957948feff3d75bdc7ca8b0e
parent 2a3e3d6ea9563355a5d28def7199b364581cffb9

Reland "Simplify layout when creating a window during tab dragging."

This is a reland of commit 8f3d075ebf5ff02504a72ac34e0adcc088376881

That CL had a flickering issue on Windows, where new windows would
appear for one frame at the top-left corner of the display before moving
to the correct offset.

The fix is to wait to show the window until its position has been set.

Original change's description:
> Simplify layout when creating a window during tab dragging.
>
> There were several compounding complexities in the old approach:
> - the window and tab bounds calculations were distributed across several
> methods, with unclear responsibilities and interactions
> - the two cases (dragging all tabs in a window, and dragging some tabs
> out into a new window) reused some of these methods, and duplicated
> (with some important differences) other parts of the logic
> - Wayland doesn't support screen coordinates or programmatically
> positioning windows; this required special handling whenever any window
> origin math was done (as that all happens in screen space)
>
> It turns out that a lot of this complexity can just cancel out if you
> arrange things the right way.
>
> This CL does several things:
> - skips calculating the detached window origin (over and over, and
> incrementally nudging the window around). The move loop will reposition
> it for us, so we can just calculate the drag offset once at the end.
> - greatly simplifies the dragging all tabs in a window case, which was
> only complicated because it was reusing too much of the other case
> - clearly defines the responsibilities of, and information flow between,
> the helper methods of DragBrowserToNewTabStrip
> - unifies calculations between Wayland (which doesn't support screen
> coordinates or programmatically positioning windows) and other platforms
> - more strictly separates the calculation of different pieces of
> information (mainly window size/origin and tab sizes/origins)
>
> Bug: 382754501
> Change-Id: Icf0296f81ee0e5b660c0a0bfd21b8e9862722a8f
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6160815
> Reviewed-by: Max Ihlenfeldt <max@igalia.com>
> Reviewed-by: David Pennington <dpenning@chromium.org>
> Reviewed-by: Nick Yamane <nickdiego@igalia.com>
> Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
> Commit-Queue: Taylor Bergquist <tbergquist@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1409303}

Bug: 382754501
Change-Id: Ic988ba017209fe274c19245da58b4955164f196e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6236187
Auto-Submit: Taylor Bergquist <tbergquist@chromium.org>
Reviewed-by: David Pennington <dpenning@chromium.org>
Commit-Queue: Taylor Bergquist <tbergquist@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1416475}