diff options
author | rlarocque@chromium.org <rlarocque@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-01-20 00:01:29 +0000 |
---|---|---|
committer | rlarocque@chromium.org <rlarocque@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-01-20 00:01:29 +0000 |
commit | 1462329583a8219fb9adee6dc95e29c927e9e165 (patch) | |
tree | a14bec890ab9c7a1c927122a2617f3adb2274b7f /chrome/browser/speech | |
parent | 51e43878421f96d21ac21740b3bca88dc34a9d53 (diff) | |
download | chromium_src-1462329583a8219fb9adee6dc95e29c927e9e165.zip chromium_src-1462329583a8219fb9adee6dc95e29c927e9e165.tar.gz chromium_src-1462329583a8219fb9adee6dc95e29c927e9e165.tar.bz2 |
Fix sync passphrase integration test reliability
This is an attempt to fix the flakiness of sync integration tests using
explicit passphrases that are affected by the race described in
crbug.com/110529.
As far as I know, this issue is not very common, though I suspect it is
related to the much more common crbug.com/95269. The reason I am
attempting to fix this is that I have some patches that change the
behaviour of the sync cycle and tend to make this issue more common.
The actual change is simple: allow clients to be considered "fully
synced" even when they require a passphrase to decrypt their contents.
Tests that require a certain cryptographer state can use the
AwaitPassphraseRequired() and AwaitPassphraseAccepted() functions to
make assertions about or wait on password state. It seems most tests
that need to make these kinds of assertions are already using those
functions, so this change does not require any changes to existing
integration tests.
BUG=110529
TEST=sync_integration_tests
Review URL: https://chromiumcodereview.appspot.com/9249047
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@118387 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/speech')
0 files changed, 0 insertions, 0 deletions