[Mac] Fix tabstrip background opacity problem when dragging tabs.

[Mac] Fix tabstrip background opacity problem when dragging tabs.

In Material Design mode, when dragging a tab out of a browser window the
dragged tab's tabstrip background becomes opaque, obscuring the window's
controls.

R=avi@chromium.org
BUG=593374
Committed: https://crrev.com/17e3629e265a12efda9e24a002009052cd922582
Cr-Commit-Position: refs/heads/master@{#385603}

[shrike, 2016-04-05 00:15:35]

PTAL

[shrike, 2016-04-05 00:50:49]

Actually, hold off on reviewing this one - it's not as simple as I thought.

[Avi (use Gerrit), 2016-04-05 01:27:33]

no problem

[shrike, 2016-04-05 18:57:29]

PTAL

I basically need to detect if the tabstrip's window is being used to drag tabs
around. Not sure if you have a better suggestion.

[Avi (use Gerrit), 2016-04-06 18:07:51]

On 2016/04/05 18:57:29, shrike wrote:
> PTAL
> 
> I basically need to detect if the tabstrip's window is being used to drag tabs
> around. Not sure if you have a better suggestion.

Do we set that as a child window? I haven't looked at the tab dragging code in a
very long while.

Maybe you can set an explicit boolean on a drag window when we do the drag?

(shrug)

[shrike, 2016-04-06 22:17:43]

On 2016/04/06 18:07:51, Avi wrote:
> On 2016/04/05 18:57:29, shrike wrote:
> > PTAL
> > 
> > I basically need to detect if the tabstrip's window is being used to drag
tabs
> > around. Not sure if you have a better suggestion.
> 
> Do we set that as a child window? I haven't looked at the tab dragging code in
a
> very long while.
> 
> Maybe you can set an explicit boolean on a drag window when we do the drag?
> 
> (shrug)

So yeah, we're creating an "overlay" window, moving the tabstrip to the overlay,
setting the overlay to be a child of the original window, and then playing with
the opacity of the original window. Setting a boolean on the dragwindow makes
sense except the tabstrip gets put in a TabWindowOverlayWindow which is an
NSWindow subclass. So the tabstrip would have to first check the window's class,
or check that it responds to the method, or we have to add a method to
TabWindowOverlayWindow and FramedBrowserWindow and all other possible kinds of
windows the tabstrip might wind up in.

I opted for an explicit bool on the tabstrip, letting it know it's in a dragging
window. At least it is explicit, and the tabstrip does not have to know about
the funky classes that are used to do the tab dragging.

PTAL

[Avi (use Gerrit), 2016-04-06 22:27:30]

lgtm

I like it being explicit a lot better.

[shrike, 2016-04-06 22:33:21]

The CQ bit was checked by shrike@chromium.org

[commit-bot: I haz the power, 2016-04-06 22:35:46]

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

[commit-bot: I haz the power, 2016-04-07 00:34:02]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-04-07 00:35:38]

Description was changed from

==========
[Mac] Fix tabstrip background opacity problem when dragging tabs.

In Material Design mode, when dragging a tab out of a browser window the
dragged tab's tabstrip background becomes opaque, obscuring the window's
controls.

R=avi@chromium.org
BUG=593374
==========

to

==========
[Mac] Fix tabstrip background opacity problem when dragging tabs.

In Material Design mode, when dragging a tab out of a browser window the
dragged tab's tabstrip background becomes opaque, obscuring the window's
controls.

R=avi@chromium.org
BUG=593374

Committed: https://crrev.com/17e3629e265a12efda9e24a002009052cd922582
Cr-Commit-Position: refs/heads/master@{#385603}
==========

[commit-bot: I haz the power, 2016-04-07 00:35:39]

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