MacViews: Use native SadTabView in mac_views_browser.

MacViews: Use native SadTabView in mac_views_browser.

Fixed SadTab in MacViews.

BUG=615871
Committed: https://crrev.com/93e85928af1507d34e3ec3735bdb041c438e1d37
Cr-Commit-Position: refs/heads/master@{#396826}

[kirr, 2016-05-30 16:08:13]

Description was changed from

==========
MacViews: Use native SadTabView in mac_views_browser.

Fixed SadTab in MacViews.

BUG=615871
==========

to

==========
MacViews: Use native SadTabView in mac_views_browser.

Fixed SadTab in MacViews.

BUG=615871
==========

[kirr, 2016-05-30 16:08:14]

kirr@yandex-team.ru changed reviewers:
+ avi@chromium.org, tapted@chromium.org

[kirr, 2016-05-30 16:13:28]

PTAL.
I'm using native cocoa view instead views::SatTabView because seems like
WebContents should be implemented above native interface and SadTabView is thing
that is attached to WebContents (change window when dragging and so on).

[Avi (use Gerrit), 2016-05-30 16:21:18]

I think that the first part of the change, moving the code to run the link to
the sad tab controller itself, is great. We have too much stuff on the browser
window controller.

I don't know whether moving to a native sad tab is the right thing. MacViews
peeps?

[tapted, 2016-05-31 12:27:22]

On 2016/05/30 16:21:18, Avi wrote:
> I think that the first part of the change, moving the code to run the link to
> the sad tab controller itself, is great. We have too much stuff on the browser
> window controller.
> 
> I don't know whether moving to a native sad tab is the right thing. MacViews
> peeps?

Yeah - this makes some sense. I haven't had time to dive in fully to how SadTabs
are plumbed in. But, since we're using a native view for the WebContentsView, I
think it's reasonable to use a native view for the SadTab as well. At least for
now. That is, we _should_ be able to get sad_tab_view.cc to work as well, and
we'll need to do that at some point, but that might be a long way down the line
(like, when we explore Aura). So if SadTabCocoa works for mac_views_browser, and
SadTabView doesn't, I think it's OK to use it for now. So long as we don't find
ourselves needing more changes to SadTabCocoa - if there's more needed to get it
working in mac_views_browser, we should be working on SadTabVIew instead.

So, lgtm if this works. But wait for avi's lg too.

[kirr, 2016-05-31 12:47:06]

The CQ bit was checked by kirr@yandex-team.ru to run a CQ dry run

[commit-bot: I haz the power, 2016-05-31 12:47:13]

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

[commit-bot: I haz the power, 2016-05-31 13:36:18]

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

[commit-bot: I haz the power, 2016-05-31 13:36:19]

Dry run: This issue passed the CQ dry run.

[Avi (use Gerrit), 2016-05-31 14:34:43]

On 2016/05/31 12:27:22, tapted wrote:
> On 2016/05/30 16:21:18, Avi wrote:
> > I think that the first part of the change, moving the code to run the link
to
> > the sad tab controller itself, is great. We have too much stuff on the
browser
> > window controller.
> > 
> > I don't know whether moving to a native sad tab is the right thing. MacViews
> > peeps?
> 
> Yeah - this makes some sense. I haven't had time to dive in fully to how
SadTabs
> are plumbed in. But, since we're using a native view for the WebContentsView,
I
> think it's reasonable to use a native view for the SadTab as well. At least
for
> now. That is, we _should_ be able to get sad_tab_view.cc to work as well, and
> we'll need to do that at some point, but that might be a long way down the
line
> (like, when we explore Aura). So if SadTabCocoa works for mac_views_browser,
and
> SadTabView doesn't, I think it's OK to use it for now. So long as we don't
find
> ourselves needing more changes to SadTabCocoa - if there's more needed to get
it
> working in mac_views_browser, we should be working on SadTabVIew instead.
> 
> So, lgtm if this works. But wait for avi's lg too.

LGTM too, then.

[kirr, 2016-05-31 14:50:00]

The CQ bit was checked by kirr@yandex-team.ru

[commit-bot: I haz the power, 2016-05-31 14:50:18]

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

[commit-bot: I haz the power, 2016-05-31 14:55:24]

Description was changed from

==========
MacViews: Use native SadTabView in mac_views_browser.

Fixed SadTab in MacViews.

BUG=615871
==========

to

==========
MacViews: Use native SadTabView in mac_views_browser.

Fixed SadTab in MacViews.

BUG=615871
==========

[commit-bot: I haz the power, 2016-05-31 14:55:24]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-31 14:56:51]

Description was changed from

==========
MacViews: Use native SadTabView in mac_views_browser.

Fixed SadTab in MacViews.

BUG=615871
==========

to

==========
MacViews: Use native SadTabView in mac_views_browser.

Fixed SadTab in MacViews.

BUG=615871

Committed: https://crrev.com/93e85928af1507d34e3ec3735bdb041c438e1d37
Cr-Commit-Position: refs/heads/master@{#396826}
==========

[commit-bot: I haz the power, 2016-05-31 14:56:52]

Patchset 1 (id:??) landed as
https://crrev.com/93e85928af1507d34e3ec3735bdb041c438e1d37
Cr-Commit-Position: refs/heads/master@{#396826}