[sync] Prevent sessions flare on startup

[sync] Prevent sessions flare on startup

SyncSessionsWebContents router triggered its flare for any notification
it received, no matter what. This caused it to trigger a flare more or
less immediately upon startup. This change caused the flare to trigger
only if the notification is meaningful; i.e. it's for a valid tab's
load completed event. This is a change from the past behavior, which
wouldn't flare for tabs that shouldn't sync, like the new tab page, but
would flare for any event type. 

R=skym@chromium.org

BUG=712372
Review-Url: https://codereview.chromium.org/2824073002
Cr-Commit-Position: refs/heads/master@{#466119}
Committed: https://chromium.googlesource.com/chromium/src/+/e8227a0e1c5fc7f230fe575086e1816a4e9fa6ae

[Patrick Noland, 2017-04-17 23:45:18]

The CQ bit was checked by pnoland@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-17 23:45:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Patrick Noland, 2017-04-17 23:53:48]

Sky,PTAL

[commit-bot: I haz the power, 2017-04-18 01:18:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-18 01:18:41]

Dry run: This issue passed the CQ dry run.

[skym, 2017-04-18 15:50:51]

Would like to see unit tests if we're going ahead with this change. Though, I
don't exactly understand why we need to flare at all. Can we just never flare
off sessions changes?

SessionsSyncManager::MergeDataAndStartSyncing calls
AssociateWindows(RELOAD_TABS, ..) and deals with having changes while sync
wasn't running.

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
File chrome/browser/sync/sessions/sync_sessions_web_contents_router.cc (right):

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
chrome/browser/sync/sessions/sync_sessions_web_contents_router.cc:63: return;
This early return feels really oddly structured.

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
chrome/browser/sync/sessions/sync_sessions_web_contents_router.cc:66: if
(!flare_.is_null()) {
This looks broken to me. My understanding is that we're given the |handler_| at
the end of SessionsSyncManager::MergeDataAndStartSyncing. If your flare call is
inside if (handler_) it will never execute when it's actually needed.

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
File chrome/browser/sync/sessions/sync_sessions_web_contents_router.h (right):

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
chrome/browser/sync/sessions/sync_sessions_web_contents_router.h:44: void
SetSyncSessionsClient(SyncSessionsClient* sessions_client) {
https://google.github.io/styleguide/cppguide.html#Function_Names

I thought the name should be something like set_sync_sessions_client(...), but
apparently that is optional. I personally like your casing more. So lets not
change anything :)

[Patrick Noland, 2017-04-18 21:58:53]

The CQ bit was checked by pnoland@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-18 21:59:20]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Patrick Noland, 2017-04-18 21:59:51]

Patchset #2 (id:20001) has been deleted

[commit-bot: I haz the power, 2017-04-18 22:07:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-18 22:07:10]

Dry run: This issue passed the CQ dry run.

[Patrick Noland, 2017-04-18 22:14:48]

The CQ bit was checked by pnoland@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-18 22:15:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Patrick Noland, 2017-04-18 22:37:42]

Sky, PTAL

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
File chrome/browser/sync/sessions/sync_sessions_web_contents_router.cc (right):

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
chrome/browser/sync/sessions/sync_sessions_web_contents_router.cc:63: return;
On 2017/04/18 15:50:51, skym wrote:
> This early return feels really oddly structured.

Done.

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
chrome/browser/sync/sessions/sync_sessions_web_contents_router.cc:66: if
(!flare_.is_null()) {
On 2017/04/18 15:50:51, skym wrote:
> This looks broken to me. My understanding is that we're given the |handler_|
at
> the end of SessionsSyncManager::MergeDataAndStartSyncing. If your flare call
is
> inside if (handler_) it will never execute when it's actually needed.

Done.

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
File chrome/browser/sync/sessions/sync_sessions_web_contents_router.h (right):

https://codereview.chromium.org/2824073002/diff/1/chrome/browser/sync/session...
chrome/browser/sync/sessions/sync_sessions_web_contents_router.h:44: void
SetSyncSessionsClient(SyncSessionsClient* sessions_client) {
On 2017/04/18 15:50:51, skym wrote:
> https://google.github.io/styleguide/cppguide.html#Function_Names
> 
> I thought the name should be something like set_sync_sessions_client(...), but
> apparently that is optional. I personally like your casing more. So lets not
> change anything :)

Acknowledged.

[skym, 2017-04-18 22:39:53]

lgtm

Can you update the CL description?

https://codereview.chromium.org/2824073002/diff/40001/chrome/browser/sync/ses...
File chrome/browser/sync/sessions/sync_sessions_web_contents_router_unittest.cc
(right):

https://codereview.chromium.org/2824073002/diff/40001/chrome/browser/sync/ses...
chrome/browser/sync/sessions/sync_sessions_web_contents_router_unittest.cc:72:
router()->InjectStartSyncFlare(
What about not having a flare and making sure we don't crash? Branch coverage!

[Patrick Noland, 2017-04-18 22:49:31]

The CQ bit was checked by pnoland@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-18 22:49:48]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Patrick Noland, 2017-04-18 22:51:20]

Description was changed from

==========
[sync] Prevent sessions flare on startup

SyncSessionsWebContents router triggered its flare for any notification
it received, no matter what. This caused it to trigger a flare more or
less immediately upon startup. This change caused the flare to trigger
only if the notification is meaningful; i.e. it's for a tab that should
sync, and there's a local event handler hooked up.

R=skym@chromium.org

BUG=712372
==========

to

==========
[sync] Prevent sessions flare on startup

SyncSessionsWebContents router triggered its flare for any notification
it received, no matter what. This caused it to trigger a flare more or
less immediately upon startup. This change caused the flare to trigger
only if the notification is meaningful; i.e. it's for a valid tab's
load completed event. This is a change from the past behavior, which
wouldn't flare for tabs that shouldn't sync, like the new tab page, but
would flare for any event type. 

R=skym@chromium.org

BUG=712372
==========

[Patrick Noland, 2017-04-18 22:52:28]

The CQ bit was checked by pnoland@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-18 22:52:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Patrick Noland, 2017-04-18 22:53:19]

https://codereview.chromium.org/2824073002/diff/40001/chrome/browser/sync/ses...
File chrome/browser/sync/sessions/sync_sessions_web_contents_router_unittest.cc
(right):

https://codereview.chromium.org/2824073002/diff/40001/chrome/browser/sync/ses...
chrome/browser/sync/sessions/sync_sessions_web_contents_router_unittest.cc:72:
router()->InjectStartSyncFlare(
On 2017/04/18 22:39:52, skym wrote:
> What about not having a flare and making sure we don't crash? Branch coverage!

Done.

[commit-bot: I haz the power, 2017-04-18 23:57:49]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-18 23:57:50]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Patrick Noland, 2017-04-19 17:36:05]

Patchset #4 (id:80001) has been deleted

[Patrick Noland, 2017-04-20 17:51:42]

The CQ bit was checked by pnoland@chromium.org to run a CQ dry run

[Patrick Noland, 2017-04-20 17:51:59]

Patchset #4 (id:100001) has been deleted

[commit-bot: I haz the power, 2017-04-20 17:52:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-20 20:37:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-04-20 20:37:47]

Dry run: This issue passed the CQ dry run.

[Patrick Noland, 2017-04-20 20:40:05]

The CQ bit was checked by pnoland@chromium.org

[Patrick Noland, 2017-04-20 20:40:06]

The patchset sent to the CQ was uploaded after l-g-t-m from skym@chromium.org
Link to the patchset: https://codereview.chromium.org/2824073002/#ps120001
(title: "Disable test on android")

[commit-bot: I haz the power, 2017-04-20 20:40:38]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-04-20 20:47:52]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1492720805648530,
"parent_rev": "e30abe9ad8527585fc6783d8abd24842b07f67b6", "commit_rev":
"e8227a0e1c5fc7f230fe575086e1816a4e9fa6ae"}

[commit-bot: I haz the power, 2017-04-20 20:47:59]

Description was changed from

==========
[sync] Prevent sessions flare on startup

SyncSessionsWebContents router triggered its flare for any notification
it received, no matter what. This caused it to trigger a flare more or
less immediately upon startup. This change caused the flare to trigger
only if the notification is meaningful; i.e. it's for a valid tab's
load completed event. This is a change from the past behavior, which
wouldn't flare for tabs that shouldn't sync, like the new tab page, but
would flare for any event type. 

R=skym@chromium.org

BUG=712372
==========

to

==========
[sync] Prevent sessions flare on startup

SyncSessionsWebContents router triggered its flare for any notification
it received, no matter what. This caused it to trigger a flare more or
less immediately upon startup. This change caused the flare to trigger
only if the notification is meaningful; i.e. it's for a valid tab's
load completed event. This is a change from the past behavior, which
wouldn't flare for tabs that shouldn't sync, like the new tab page, but
would flare for any event type. 

R=skym@chromium.org

BUG=712372

Review-Url: https://codereview.chromium.org/2824073002
Cr-Commit-Position: refs/heads/master@{#466119}
Committed:
https://chromium.googlesource.com/chromium/src/+/e8227a0e1c5fc7f230fe575086e1...
==========

[commit-bot: I haz the power, 2017-04-20 20:48:01]

Committed patchset #4 (id:120001) as
https://chromium.googlesource.com/chromium/src/+/e8227a0e1c5fc7f230fe575086e1...