Issue 747152  has been merged into this issue.

I can repro this issue on HTC U11 and Pixel on 61.0.3162.3.
Not reproducible on 60.0.3112.73 
Will provide bisect info soon

I'll be OOO Friday and Monday, so cc'ing Ted to help triage if a bisect comes in while I'm gone. Nothing that changed recently in the Java manager is likely to have caused this.

+ewald, are you aware of any changes in sign in that would make deleting the bookmarks now the expected behavior?

​61.0.3157.3(GOOD)
61.0.3158.0(BAD).​

CL range: https://chromium.googlesource.com/chromium/src/+log/61.0.3157.0..61.0.3158.0?pretty=fuller&n=10000

I am not able to perform per cl bisect as lot of in-between are crashing and I'm encountering sync issues. 

Possibly this? "Delete Google service worker caches on Android signout." https://chromium.googlesource.com/chromium/src/+/0e575f680905fdd810dd4e5a8af2f120d03450da

Naively, Martin's change seems like a potential candidate. I don't think we're made any other changes to the signin code on Android recently that would affect this (+Boris and +Mihai to confirm).

I don't see it so far...

Apart from deleting service workers, we call SigninManager.WipeDataHooks(), but that should only handle the UI, not perform any additional deletions.

Questions:
- Did you see this happen with other data corpus than bookmarks, e.g. history?
- Is this a managed device?

History is fine and it is not a managed device.

Alright, this one is on me. Bookmarks are deleted in SigninManagerAndroid in the callback from BrowsingDataRemover. We reuse that callback when deleting service workers, accidentally deleting bookmarks as well.

I'll upload a fix shortly.

After that, we'll want to support bookmarks deletion from BrowsingDataRemover, so that SigninManagerAndroid can delete everything in a single way rather than having a special path for bookmarks.

Fix is here: https://canary-chromium-review.googlesource.com/c/581497/

Also added unittests for when bookmarks should and shouldn't be deleted, and tested manually.

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

commit d2fe8ebb71e77a5b05e3fe9c0ca8711fe4e51ab1
Author: Martin Sramek <msramek@chromium.org>
Date: Tue Jul 25 16:59:40 2017

Ensure signing out deletes bookmarks only if full wipe is requested

Due to a bug in https://codereview.chromium.org/2966763003/, bookmarks
were being deleted when a non-managed user signed out, in which case
only Google service worker caches should have been deleted.

This CL fixes the problem and adds a unittest for bookmark deletion
in both cases.

Note that making bookmarks deletion testable required moving it into
ProfileDataRemover where the rest of the deletion occurs. However,
it happens on the same thread; and in any case, this is exactly the
part that is tested.

Bug:  747155 
Change-Id: I857e52cd4835d95e712e205c8c436adec73d1789
Reviewed-on: https://chromium-review.googlesource.com/581497
Commit-Queue: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Boris Sazonov <bsazonov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489343}
[modify] https://crrev.com/d2fe8ebb71e77a5b05e3fe9c0ca8711fe4e51ab1/chrome/browser/android/signin/signin_manager_android.cc
[modify] https://crrev.com/d2fe8ebb71e77a5b05e3fe9c0ca8711fe4e51ab1/chrome/browser/android/signin/signin_manager_android.h
[modify] https://crrev.com/d2fe8ebb71e77a5b05e3fe9c0ca8711fe4e51ab1/chrome/browser/android/signin/signin_manager_android_unittest.cc

This should be fixed in the next Canary. I'll ask for merge once I try it out.

Huge thanks jnaveen@ for discovering and bsazonov@ for your review.

 Issue 747161  has been merged into this issue.

The fix appeared in Canary 62.0.3168.3 today and works correctly.

Requesting merge. Justification: This is a beta blocker as it causes accidental loss of user data.

Thanks for the quick fix Martin!

Well, sorry for breaking it in the first place.

+cc Alex explicitly. There is normally a bot auto-response a few minutes after adding the Merge-Request label, and today there was not, so I'm a bit concerned whether this is on your radar...

Yeah does appear to be a bot glitch. Merge approved for 61 branch 3163. 

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

commit a0e09db75389e04f35c4e5e26060718c30ca7d91
Author: Martin Sramek <msramek@chromium.org>
Date: Fri Jul 28 19:24:48 2017

Ensure signing out deletes bookmarks only if full wipe is requested

Due to a bug in https://codereview.chromium.org/2966763003/, bookmarks
were being deleted when a non-managed user signed out, in which case
only Google service worker caches should have been deleted.

This CL fixes the problem and adds a unittest for bookmark deletion
in both cases.

Note that making bookmarks deletion testable required moving it into
ProfileDataRemover where the rest of the deletion occurs. However,
it happens on the same thread; and in any case, this is exactly the
part that is tested.

TBR=msramek@chromium.org

(cherry picked from commit d2fe8ebb71e77a5b05e3fe9c0ca8711fe4e51ab1)

Bug:  747155 
Change-Id: I857e52cd4835d95e712e205c8c436adec73d1789
Reviewed-on: https://chromium-review.googlesource.com/581497
Commit-Queue: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Boris Sazonov <bsazonov@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#489343}
Reviewed-on: https://chromium-review.googlesource.com/591849
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#110}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/a0e09db75389e04f35c4e5e26060718c30ca7d91/chrome/browser/android/signin/signin_manager_android.cc
[modify] https://crrev.com/a0e09db75389e04f35c4e5e26060718c30ca7d91/chrome/browser/android/signin/signin_manager_android.h
[modify] https://crrev.com/a0e09db75389e04f35c4e5e26060718c30ca7d91/chrome/browser/android/signin/signin_manager_android_unittest.cc

Merged. Thanks!

This issue is now not reproducible on latest M61-61.0.3163.20, hence verified