[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 Review-Url: https://codereview.chromium.org/2325893002 Cr-Commit-Position: refs/heads/master@{#417518}
Showing
Please register or sign in to comment