[Sync] Add support for identifying tabbed activites

components/sync/protocol/session_specifics.proto

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 //
 // Sync protocol datatype extension for sessions.
 
 // Update proto_value_conversions{.h,.cc,_unittest.cc} if you change
 // any fields in this file.
 
 syntax = "proto2";
@@ skipping 22 matching lines @@
   optional string client_name = 3;
   // The type of device.
   optional SyncEnums.DeviceType device_type = 4;
 }
 
 message SessionWindow {
   // Unique (to the owner) id for this window.
   optional int32 window_id = 1;
   // Index of the selected tab in tabs; -1 if no tab is selected.
   optional int32 selected_tab_index = 2 [default = -1];
-  // Type of the browser. Currently we only store browsers of type
-  // TYPE_TABBED and TYPE_POPUP.
+  // Type of the window.
   enum BrowserType {

[Ted C, 2016/11/08 00:41:45]

I'll start with naive questioning here.

Can this be exposed to stuff outside of sync?  Could it then be exposed to java
(I don't know if we generate java code from our protos or not).

Ideally, I think we would expose GetSyncBrowserType in the sync delegate and we
could pass this down.

In general, I would like to avoid the instanceof check of the
TabbedModeTabPersistencePolicy because that really shouldn't belong in the
package that it is in and I want to avoid any new dependencies.

My "hope" would be that we could expose this to java, then the constructor of
TabModelSelectorImpl and TabModelImpl would take the sync type and pass it to
jni.

If we can't expose the constant, I think a boolean isTabbedTypeForSync or
something similarly gross and long would be my second option.

[Nicolas Zea, 2016/11/08 20:52:40]

Hmm. I think there's a question of whether the TabModel should be aware of Tab
Sync semantics, or whether Tab Sync should be aware of Tab semantics. I lean
towards the latter, as Tab Sync already depends on window/tab details, and the
tab model really doesn't (and likely won't in the future) need to know anything
about Sync proto details. As such, having some way of asking the tab model "what
kind of activity are you in" is what I was thinking.

That said, we do in fact generate java code from protos, at least for
instrumentation tests (org.chromium.components.sync.protocol). Just so I
understand, what would eventually implement the GetSyncBrowserType method, and
how would it determine what to return?

I'm fine with using something different than instanceof (e.g. plumbing something
in to the TabModelSelectorImpl at construction time) if that's preferable.

-    TYPE_TABBED = 1;
-    TYPE_POPUP = 2;
+    TYPE_TABBED = 1;      // A normal tabbed window.
+    TYPE_POPUP = 2;       // A popup window.
+    TYPE_CUSTOM_TAB = 3;  // A custom tab within an app. Not restored
+                          // automatically on sync startup.
   }
   optional BrowserType browser_type = 3 [default = TYPE_TABBED];
   // The tabs that compose a window (correspond to tab id's).
   repeated int32 tab = 4;
 }
 
 message SessionTab {
   // Unique (to the owner) id for this tab.
   optional int32 tab_id = 1;
   // The unique id for the window this tab belongs to.
@@ skipping 97 matching lines @@
   }
   // Whether the Password Manager saw a password field on the page.
   optional PasswordState password_state = 26;
 }
 
 // Navigation information for a single redirection within a single navigation.
 message NavigationRedirect {
   // A URL that redirected while navigating to the virtual_url.
   optional string url = 1;
 }