diff options
author | zea@chromium.org <zea@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-04-04 02:14:32 +0000 |
---|---|---|
committer | zea@chromium.org <zea@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-04-04 02:14:32 +0000 |
commit | e91a92c7c3a84d16b41232987213ef916bc6876a (patch) | |
tree | f03773cf9caa1444cbe1e59a0dd607811a793a3e /third_party | |
parent | 1cb860667c51472ff266e6b74042414d8bb0cbc0 (diff) | |
download | chromium_src-e91a92c7c3a84d16b41232987213ef916bc6876a.zip chromium_src-e91a92c7c3a84d16b41232987213ef916bc6876a.tar.gz chromium_src-e91a92c7c3a84d16b41232987213ef916bc6876a.tar.bz2 |
[Sync] Fix reassociation when tab nodes have been only partially removed.
We would reassociate under the assumption that the number of free tab nodes
matched the tags of the tab nodes (i.e. all tab nodes have a tag based on an
id < the number of free tab nodes). When other clients delete stale sessions,
they're not guaranteed to have all the nodes, and so may delete only a subset
of the tab nodes. On the next reassociation, the previously-stale client will
not properly track the pre-existing tab nodes. Specifically, the tab nodes
it adds to its free pool may have tags based on ids larger than the free pool.
To simplify this, we just delete all pre-existing tab nodes at association time.
In addition, to lay the groundwork for future support of reassociation, we now
also have a field in each tab node that provides the actual tab id used to create the
client tag for that node. We can then eventually use that id to do tag based
lookups instead of relying on size of our tab pool.
BUG=121783
TEST=unit_tests
Review URL: https://chromiumcodereview.appspot.com/9968114
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130541 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'third_party')
0 files changed, 0 insertions, 0 deletions