New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 731824 link

Starred by 3 users
Status: Fixed
Owner:
rdevlin....@chromium.org
Closed: Aug 2017
Cc:
karandeepb@chromium.org
mfo...@chromium.org
lazyboy@chromium.org
sko...@chromium.org
mastiz@chromium.org
█ tschumann@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Extensions shouldn't apply sync data if the extension is unsyncable

Project Member Reported by rdevlin....@chromium.org, Jun 9 2017 
What steps will reproduce the problem?
1. Have Extension Alpha default-installed on one machine and user-installed on another.
2. Turn on extension sync.
3. Disable Extension Alpha on the user-installed machine.

What is the expected result?
The extension should not be disabled on the default-installed machine, since we don't sync default-installed extensions.  At minimum, the extension should be able to be re-enabled on the default-installed machine.

What happens instead of that?
The extension is continually disabled on the default-installed machine.

Please provide any additional information below. Attach a screenshot if
possible.

Since we don't sync default-installed extensions (by design), this means that the data in the sync server will always be from the user-installed machine.  If the user disables an extension on a user-installed machine, this will be synced, and pulled onto all machines.  Even if the user then re-enables the extension on the default-installed machine, it won't get pushed to sync, and when we next pull from sync, the extension will be disabled again.
Project Member

Comment 1 by bugdroid1@chromium.org, Jun 13 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2f1ed4c9530785eab233370a9e8429451d987515

commit 2f1ed4c9530785eab233370a9e8429451d987515
Author: rdevlin.cronin <rdevlin.cronin@chromium.org>
Date: Tue Jun 13 16:22:13 2017

[Extensions Sync] Don't apply sync data for unsyncable extensions

Some extensions are considered "unsyncable" - this includes extensions
that are installed by default (since we don't want to push them to
propogate everywhere). However, we weren't checking if an extension
was syncable before applying the sync data from the server. This meant
that it was possible to get into a bad state where, if a user has an
extension that is default installed on one machine, but not another, the
extension would be synced down, but never updated. In one case, this
can result in the extension always becoming disabled.

Fix this by checking for if an extension is syncable before applying
sync data, and add a couple of tests.

BUG= 731824 

Review-Url: https://codereview.chromium.org/2923013006
Cr-Commit-Position: refs/heads/master@{#479039}

[modify] https://crrev.com/2f1ed4c9530785eab233370a9e8429451d987515/chrome/browser/extensions/chrome_test_extension_loader.cc
[modify] https://crrev.com/2f1ed4c9530785eab233370a9e8429451d987515/chrome/browser/extensions/extension_service_sync_unittest.cc
[modify] https://crrev.com/2f1ed4c9530785eab233370a9e8429451d987515/chrome/browser/extensions/extension_sync_service.cc

Comment 2 by rdevlin....@chromium.org, Aug 2 2017

Status: Fixed (was: Started)

Comment 3 by mfo...@chromium.org, Aug 23 2017

Cc: sko...@chromium.org mfo...@chromium.org
Devlin,

Do we know how many users have extensions in a synced-but-disabled state?  If this happens to the Media Router component, it would result in users with a broken Cast experience.

It looks like the patch prevents future occurrences, but doesn't repair existing disabled extensions.
►

Sign in to add a comment