[blimp] Add support for having multiple tabs

[blimp] Add support for having multiple tabs

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774
Committed: https://crrev.com/d464f5a8d6f8570da079b8a6368bc3c1b145dcf9
Cr-Commit-Position: refs/heads/master@{#417518}

[nyquist, 2016-09-09 00:51:59]

The CQ bit was checked by nyquist@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-09 00:52:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nyquist, 2016-09-09 00:54:46]

Description was changed from

==========
Add support for having multiple tabs with blimp.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774
==========

to

==========
[blimp] Add support for having multiple tabs

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774
==========

[nyquist, 2016-09-09 01:37:04]

nyquist@chromium.org changed reviewers:
+ dtrainor@chromium.org

[nyquist, 2016-09-09 01:37:05]

dtrainor: PTAL

[nyquist, 2016-09-09 02:46:24]

The CQ bit was checked by nyquist@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-09 02:46:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-09 03:31:04]

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

[commit-bot: I haz the power, 2016-09-09 03:31:05]

Dry run: This issue passed the CQ dry run.

[David Trainor- moved to gerrit, 2016-09-09 05:44:48]

lgtm

[nyquist, 2016-09-09 06:27:35]

The CQ bit was checked by nyquist@chromium.org

[commit-bot: I haz the power, 2016-09-09 06:27:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-09 06:33:34]

Description was changed from

==========
[blimp] Add support for having multiple tabs

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774
==========

to

==========
[blimp] Add support for having multiple tabs

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774
==========

[commit-bot: I haz the power, 2016-09-09 06:33:35]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-09-09 06:35:20]

Description was changed from

==========
[blimp] Add support for having multiple tabs

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774
==========

to

==========
[blimp] Add support for having multiple tabs

There is still only a single Blimp tab, and the logic is for now very
simple: If there is already a blimp tab available, a new tab will be
WebContents based. If there are no blimp tabs, a blimp-based tab will
be created.

Also, when tabs are closed, it takes a while before the tab is really
destroyed, in case the user wants to undo the action. This feature
stays, but if the user selects "New Tab" or clicks the new tab button,
all the pending closures are first committed, ensuring that the tab
to be created might become a blimp tab, even if the current blimp tab
was pending closure.

Before this CL, the value 0 was always used fro the tab ID. This meant
that there would be a mixup between tabs that are closed and new tabs
that are created. This CL changes this so that each BlimpContentsImpl
gets its own unique ID, created client-side, and transferred to the
engine to be used for all communication regarding that tab, by an
update to the TabControlFeature to now include the ID.

The NavigationFeature is also updated to support receiving messages
after BlimpContentsImpl has been destroyed, which may happen, and
it now just logs those errors.

To ensure that this is visible in the tab switcher as well, a
workaround is added to ensure that the theme color is always shown,
even when on the new tab page. This is important in case where there
are many new tab pages, and one can not see which one is the blimp
tab, since the theme color is only updated when the tab navigates
away from the NTP.

To support the multiple IDs on the engine side, the Tab class is now
the implementor of the
EngineRenderWidgetFeature::RenderWidgetMessageDelegate instead of the
BlimpEngineSession. IME and compositor protos use the ID of the current
tab for their messages.

BUG=644467, 644774

Committed: https://crrev.com/d464f5a8d6f8570da079b8a6368bc3c1b145dcf9
Cr-Commit-Position: refs/heads/master@{#417518}
==========

[commit-bot: I haz the power, 2016-09-09 06:35:20]

Patchset 2 (id:??) landed as
https://crrev.com/d464f5a8d6f8570da079b8a6368bc3c1b145dcf9
Cr-Commit-Position: refs/heads/master@{#417518}