Support remote installation of extensions and apps.

sync/protocol/extension_specifics.proto

Index: sync/protocol/extension_specifics.proto
diff --git a/sync/protocol/extension_specifics.proto b/sync/protocol/extension_specifics.proto
index 05120d323c1d728d016a577d59158c3f47d9be0f..2ea179440860fc7b8bdecce346cee620f9300bff 100644
--- a/sync/protocol/extension_specifics.proto
+++ b/sync/protocol/extension_specifics.proto
@@ -35,5 +35,8 @@ message ExtensionSpecifics {
 
   // The name of the extension. Used for bookmark apps.
   optional string name = 6;
+
+  // Whether this extension is being installed remotely.
+  optional bool remote_install = 7;

[Yoyo Zhou, 2014/05/01 22:53:44]

When changing proto fields, you'll want to test the behavior when you sync
between new and old versions (in both directions). I think unexpected things can
happen when you sync a field to a client that doesn't recognize it, even though
proto are supposed to be able to cope.

[Marijn Kruisselbrink, 2014/05/05 20:45:36]

I think this should be fine, assuming that old clients won't cause this field to
be deleted on the server...
One potentially problematic interaction happens when a user on an old client
would enable a remotely installed extension (in this case the user won't get to
see a permission prompt, since old chrome assumes that something in sync has
already prompted in the past). After this sync would have enabled == true and
remote_install == true at the same time (which means the next time a newer
client updates sync data, it will set remote_install to false, again without
ever prompting the user for permissions).

[Yoyo Zhou, 2014/05/05 22:35:16]

I'd strongly encourage you to test this (you may have to manually).
So this would happen if the old client doesn't set remote_install (because it
doesn't know about it), right? As I mentioned, if protos worked exactly as
expected, this is what should happen, but I believe it's possible that the lack
of the field would be interpreted as "false".

[Marijn Kruisselbrink, 2014/05/14 23:30:02]

Unfortunately I haven't been able to test chrome with a local sync server (that
actually understands this new field). In current chrome ToT logging with a
gaiastaging account and/or using a local sync server is completely broken (can't
log in, if I trick it to be logged in various sync things crash chrome).
(actually, I think I did manage to log in with an older chrome version, so I
should be able to test the behavior of an older chrome with this new field, but
not sure how I'd actually see what happens to this field if a client that
doesn't know about the field is the only one I can get to talk to my sync
server).
Well, there isn't much we can do about old chrome versions... If the result of
an old chrome version being signed in to sync is that it will always set this
field to "false", than that is what happens, and nothing we can do about it. I
think this is more a question of how the sync server deals with missing fields
than how old clients do. If the server does it "right" (where right means not
change the field when a client doesn't mention the field at all), things will
work as expected.

 }