| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Google Talk server will reject connection attempts made with a stale
access token. This is often not a problem because we only need to
connect on startup, when the token is fresh. It becomes a problem if we
temporarily lose the network connection and need to reconnect.
This change updates the TiclInvalidationService so it requests an
updated access token when it receives a credentials rejected error.
This should allow it to recover from connection failures caused by stale
access tokens.
TEST=Manual. Sign in to sync, wait > 1 hour, disable network
connection, then re-enable it. Verify notifier state is enabled.
BUG=264455
Review URL: https://chromiumcodereview.appspot.com/21140004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@215094 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
TBR=jochen@chromium.org
BUG=244891
Review URL: https://chromiumcodereview.appspot.com/18526004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@214760 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=263287
Review URL: https://chromiumcodereview.appspot.com/19733003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@214555 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
When signout occurs, the TiclInvalidationService should't care about the
results of any pending OAuth2 access token requests. This change
modifies the logout function to cancel any pending requests.
BUG=258357
Review URL: https://chromiumcodereview.appspot.com/19287012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212691 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=260021
Review URL: https://chromiumcodereview.appspot.com/19381005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212448 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=260807
TEST=none
TBR=ben@chromium.org
Review URL: https://chromiumcodereview.appspot.com/19602003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@212332 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the detail type of NOTIFICATION_SYNC_REFRESH_LOCAL notifications
from ModelTypeInvaliationMap to ModelTypeSet. The map was unnecessary
because these notifications never include a payload.
Change the detail types of NOTIFICATION_SYNC_REFRESH_REMOTE
notifications from ModelTypeSet to ObjectIdInvalidationMap. This will
allow the Android invalidator to forward invalidations that are not
associated with sync types.
TBR=jhawkins
BUG=224161
Review URL: https://chromiumcodereview.appspot.com/18405002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211301 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
TBR=brettw
Review URL: https://codereview.chromium.org/19074002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211285 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DCHECK was intended to make sure that we've bothered to fetch an
access token by the time we call UpdateInvalidatorCredentials(). That
seemed like a reasonable assertion. However, if we're calling
UpdateInvalidatorCredentials with the intention of clearing the token
(which can happen when we receive NOTIFICATION_TOKENS_CLEARED) the
DCHECK will fail.
BUG=259320
Review URL: https://chromiumcodereview.appspot.com/18565007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@211224 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL is a prerequisite for putting Chrome in charge of all power
management settings. Since the power management defaults on the login
screen differ from those during a user session, the default values of
the power prefs should be set differently for the login profile.
This CL has no functional changes. It just does the following:
1/ Split chrome::RegisterUserPrefs() into:
* chrome::RegisterUserProfilePrefs()
* chrome::RegisterLoginProfilePrefs()
2/ Rename all other RegisterUserPrefs() methods to RegisterProfilePrefs().
BUG=241794
TEST=Updated unit and browser tests
TBR=jochen@chromium.org (blanket rename of RegisterUserPrefs() in chrome/)
TBR=asargent@chromium.org (blanket rename of RegisterUserPrefs() in apps/)
TBR=joi@chromium.org (blanket rename of RegisterUserPrefs() in components/)
Review URL: https://chromiumcodereview.appspot.com/18199003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@210310 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
This doesn't actually do very much. The dependency appears to have gone
away on its own.
BUG=243482
Review URL: https://chromiumcodereview.appspot.com/18390002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209551 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The InvalidationService was introduced r199520. That commit added the
InvalidationService interface and several implementations of it, but
made no use of the new code. This commit builds on that work.
Up until now, TICL invalidations were handled on the sync thread. The
related objects were instantiated and owned by the SyncBackendHost and
SyncManager. All requests to update the set of object registrations had
to be passed to the sync thread. Components that wanted to receive
invalidations but were not part of sync had to route their communication
with the invalidations server through ProfileSyncService to get to the
sync thread. Things were a bit different on Android, but the system
still tried to pretend that invalidations were owned by the sync thread.
The new InvalidationService implementation is a ProfileKeyedService that
is mostly independent from sync. It still relies on sync to manage sign
in and fetch the appropriate auth tokens. However, it's now much easier
for components outside of sync to communication with the invalidations
server.
The new system allows us to remove a lot of invalidations-related code
from the ProfileSyncService, SyncBackendHost and SyncManager. Sync is
now just one of many clients of the InvalidationService. The
SyncBackendHost is responsible for forwarding messages back and forth
between the InvalidationService and the sync thread.
TBR=dcheng,satorux1,battre,rsimha,bauerb,sky,erg
BUG=124137
Review URL: https://chromiumcodereview.appspot.com/17699005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@209264 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Make use of InvalidationService
>
> The InvalidationService was introduced r199520. That commit added the
> InvalidationService interface and several implementations of it, but
> made no use of the new code. This commit builds on that work.
>
> Up until now, TICL invalidations were handled on the sync thread. The
> related objects were instantiated and owned by the SyncBackendHost and
> SyncManager. All requests to update the set of object registrations had
> to be passed to the sync thread. Components that wanted to receive
> invalidations but were not part of sync had to route their communication
> with the invalidations server through ProfileSyncService to get to the
> sync thread. Things were a bit different on Android, but the system
> still tried to pretend that invalidations were owned by the sync thread.
>
> The new InvalidationService implementation is a ProfileKeyedService that
> is mostly independent from sync. It still relies on sync to manage sign
> in and fetch the appropriate auth tokens. However, it's now much easier
> for components outside of sync to communication with the invalidations
> server.
>
> The new system allows us to remove a lot of invalidations-related code
> from the ProfileSyncService, SyncBackendHost and SyncManager. Sync is
> now just one of many clients of the InvalidationService. The
> SyncBackendHost is responsible for forwarding messages back and forth
> between the InvalidationService and the sync thread.
>
> TBR=sky,erg
> BUG=124137
>
> Review URL: https://chromiumcodereview.appspot.com/15580002
TBR=rlarocque@chromium.org
Review URL: https://codereview.chromium.org/17610004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208347 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The InvalidationService was introduced r199520. That commit added the
InvalidationService interface and several implementations of it, but
made no use of the new code. This commit builds on that work.
Up until now, TICL invalidations were handled on the sync thread. The
related objects were instantiated and owned by the SyncBackendHost and
SyncManager. All requests to update the set of object registrations had
to be passed to the sync thread. Components that wanted to receive
invalidations but were not part of sync had to route their communication
with the invalidations server through ProfileSyncService to get to the
sync thread. Things were a bit different on Android, but the system
still tried to pretend that invalidations were owned by the sync thread.
The new InvalidationService implementation is a ProfileKeyedService that
is mostly independent from sync. It still relies on sync to manage sign
in and fetch the appropriate auth tokens. However, it's now much easier
for components outside of sync to communication with the invalidations
server.
The new system allows us to remove a lot of invalidations-related code
from the ProfileSyncService, SyncBackendHost and SyncManager. Sync is
now just one of many clients of the InvalidationService. The
SyncBackendHost is responsible for forwarding messages back and forth
between the InvalidationService and the sync thread.
TBR=sky,erg
BUG=124137
Review URL: https://chromiumcodereview.appspot.com/15580002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@208315 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=247723
TEST=none
TBR=ben@chromium.org
Review URL: https://chromiumcodereview.appspot.com/15798020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205375 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
To create a managed user, someone has to be signed in. We
store the username immediately after the new managed profile
has been created as a profile preference.
BUG=241387
Review URL: https://chromiumcodereview.appspot.com/15907009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@204660 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL updates chrome/browser/* other than chrome/browser/ui which is in
another CL.
BUG=236029
TBR=brettw
Review URL: https://chromiumcodereview.appspot.com/14113053
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@202664 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=227219
R=joi@chromium.org
Review URL: https://codereview.chromium.org/15517005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201634 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Renames of the classes and methods will follow in separate patch(es).
BUG=227219
R=erg@chromium.org, joi@chromium.org
Review URL: https://codereview.chromium.org/14743010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201167 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first issue is that TiclInvalidationService should only respond to
invalidations related to its own profile. That's been fixed by passing
the appropriate parameters when registering with the notification
service.
Second, the management of the invalidator storage within the
TiclInvalidationService has been modified. Clients of this service
could ask for the invalidation client ID at any time, and we must be
prepared to send them a valid response. Therefore, it is not possible
to allow the TiclInvalidationService to exist without a valid
InvalidatorStorage member.
Fortunately, the InvalidationService code is not currently in use, so
these bugs were harmless.
BUG=124137
Review URL: https://chromiumcodereview.appspot.com/15176003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@201120 0039d316-1c4b-4281-b951-d872f2087c98
|
|
This commit introduces a new ProfileKeyedService, the
InvalidationService. Clients may register with this service to receive
notifications from a server informing them when they need to fetch
updates to their cached state. (In other words, they will receive
notifications when their cache has become invalid.)
There are three different implementations of this service, all of which
inherit from InvalidationFrontend. The current provider of
invalidations, ProfileSyncService, also inherits from this interface.
The TiclInvalidationService receives notifications through the C++
version of the googlecacheinvalidation (aka. TICL) library. It is used
on Chromium for Desktop operating systems.
The AndroidInvalidationService receives notifications by listening to
the in-process NotificationService
(content/public/browser/notification_service.h). The code that actually
sends these notifications is a small bridge from Java-land, which is not
affected by this CL.
The P2PInvalidationService uses XMPP peer-to-peer connections to send
and receive invalidations. This has not been used in Chromium for a
very long time. We keep it around because some of our integration
tests rely on it.
This CL also includes an InvalidationServiceFactory to help manage the
selection and construction of these InvalidationServices.
The tests for these new services are based on a modified version of
sync/notifier/invalidator_test_template.h. The P2PInvalidationService
is not tested at all because it is itself a test-only utility.
In addition to the new code, this CL moves around some old code to help
populate a new directory, chrome/browser/invalidation. We're trying to
separate invalidations from sync, so the
chrome/browser/sync/invalidations directory was no longer needed.
Finally, note that this commit does not change Chromium in any way. It
adds new classes and test for them, but the rest of the code has not
been modified to make use of them. Those changes will happen in a
future CL.
BUG=124137
Review URL: https://chromiumcodereview.appspot.com/13991017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@199520 0039d316-1c4b-4281-b951-d872f2087c98
|