Putting this down for attention in 51

Unfortunately, it seems that I do not have access to that link.

However, I do not understand this report. Clicking "Clear browsing data" is not supposed to delete history immediately. It opens the Clear Browsing Data dialog, where user can select history (as well as other data types) for deletion.

(1) Go to Chrome Menu
(2) Click History
(3) Click "Clear browsing data"
(4) Check "Browsing history"
(5) [Optional] Select time range
(6) Click "Clear data"

Expected:
(7) The dialog is closed, and the user is returned to the history page, which is now empty, because history entries have been deleted.

This works for me on Nexus 5 and Samsung Galaxy 5 devices on which I just tested, and was tested on a range of devices in issue 588777.

Considering the phrase 'you can only delete browsing data one by one by clicking "x"', there seems to be a misunderstanding that history items are the only type of browsing data. Could it be that the dialog is not opened for some users, and therefore they think that the button should do something immediately? Can you provide more details from the reports?

Oh actually, now I noticed the version in your report:

Version: <49.0.2623.105>
OS: <Android 5.1>

All my recent changes to the Clear Browsing Data dialog are in M50, so they can't be the cause; in fact, they may inadvertently make the report obsolete, as the dialog works quite differently from how it did in M49.

(I'm still interested in reading more from the reports though.)

msramek@
You should be able to see the feedback reports now. 

We see user feedback about this issue on M50 as well. I can reproduce it on Nexus 5+Aneroid 5.1 and Nexus 6+Android 6.0.1.
However, I found that after several attempts to clear browsing data and going back and forth in the Chrome setting, the browsing data was eventually cleared somehow.

https://youtu.be/dBk99q_O94c
https://youtu.be/oTn-HywUYzA 

Thank you, the videos were very helpful!

Clearing browsing data talks to the same backend as the data volume counters in the dialog. If the counter under history says "none", then I'm confident that the history was actually deleted.

What seems to be the problem is that when you clear the data, we just close the dialog and return to the history tab in the exactly same state in which it was before, which is now outdated. If you reload the tab, it should be empty (which you can see in the videos when you open a new history tab).

And this behavior is really reproducible in M49 as well as M50. I'll see if we can reload the history page when we return from the CBD dialog, though the user could theoretically minimize the settings activity, switch to the history tab and close it, or something like that.

[Bulk edit]

We're cutting our Android stable candidate for M51 on Tues May 24, one week from today.  This bug has been marked as a stable blocker and needs to be fixed on trunk and merged back to release branch 2704 ASAP.

If you are sure this bug should not block the release, please remove the ReleaseBlock-Stable label.  If you're not sure, or you won't be able to fix it in time, please let me know by CCing me to this bug.

Thanks!

I have implemented what I mentioned in #8, but then I realized that it has no effect, since the history page listens to HistoryService and updates itself on successful deletion. 

However, as I mentioned, in the CBD dialog it's correctly indicated that there is no history, so the problem is definitely on the history page.

My next suspicion was that only one history page would be correctly reloaded in case there are more instances of it, but no, that seems to work fine.

I have been intermittently debugging this, but I can't find the culprit, because I cannot reproduce the problem *at all*. History is being properly deleted on my device with every attempt, and immediately reflected on both "chrome://history" and "chrome://history-frame" pages. This is true both for unsigned and signed accounts, with and without synced history from other devices. It's not a device-related problem, since we're both using Nexus 5.

+hongchichang@ Could you perhaps provide more detailed instructions, in case we're doing something differently? Ideally from reinstalling Chrome?

+amineer@ In the meantime, can I ask you to punt or remove the blocking label? I am still looking into the problem, but will likely not be able to solve it by the stable cut. I think removing the label is permissible, because:

- This problem apparently exists for some time now, and is not an M-51 regression.
- The history items are in fact deleted, only the history page fails to reflects so.
- Most users visit the CBD dialog from the history page, where they are returned after the deletion, so they are immediately aware of the privacy risk of history page still showing the data, and can take an action. Removing the items individually fixes the problem, and using the CBD dialog again eventually does as well.
- The bug is not consistently reproducible (and in my case at all).

I would want to consult the privacy team, but since you are the privacy team, I guess we're OK, unless kerz@ objects.

I will remove the blocker but let's try to get this done for M52.

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 624454  has been merged into this issue.

This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit d39070b1ac01776e5a3800a9ef55fe43dce74225
Author: msramek <msramek@chromium.org>
Date: Fri Aug 26 09:46:29 2016

Make BrowsingDataHandler observe WebHistoryService deletions

BrowsingDataHandler observes local history deletions, but not synced
history deletions. In cases where there are no local history entries
to delete, it can happen that the history page does not reload and it
looks as if the deletion failed.

See https://docs.google.com/document/d/1Fd6CdBf6UMbYbkwSjEKyFOxew0Xid5IaT-QwnFchjig/
for background.

This CL
1. Adds an Observer subclass to the WebHistoryService.
2. Registers BrowsingHistoryHandler as a WebHistoryService::Observer;
   and since WebHistoryService's existence is based on whether history
   sync is enabled, we also register as a SyncServiceObserver.
3. Adds a test to browsing_history_handler_unittest.cc.

Also tested manually on Android - seems to solve the problem described
in the above mentioned document.

BUG= 604114 , 630164 

Review-Url: https://codereview.chromium.org/2263613002
Cr-Commit-Position: refs/heads/master@{#414679}

[modify] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/chrome/browser/ui/webui/browsing_history_handler.cc
[modify] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/chrome/browser/ui/webui/browsing_history_handler.h
[modify] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/chrome/browser/ui/webui/browsing_history_handler_unittest.cc
[modify] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/components/history/core/browser/BUILD.gn
[modify] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/components/history/core/browser/web_history_service.cc
[modify] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/components/history/core/browser/web_history_service.h
[add] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/components/history/core/browser/web_history_service_observer.h
[modify] https://crrev.com/d39070b1ac01776e5a3800a9ef55fe43dce74225/components/history/core/test/fake_web_history_service.cc

To wrap this bug up - I wasn't able to find cases where history wouldn't be in fact deleted, but I was able to reproduce the steps

1. Open history page.
2. Open the CBD dialog.
3. Delete history.
4. Return to the history page, still see history entries that should have been deleted.

in the cases where these conditions hold:
- history is deleted for a finite time period in step #3
- synced history takes slightly longer to delete than local history OR there is no local history

The document https://docs.google.com/document/d/1Fd6CdBf6UMbYbkwSjEKyFOxew0Xid5IaT-QwnFchjig/ explains my findings.

In all user reports where I could tell whether the user has synced history they did have it, which is evidence that it was really the same problem. The screencap in comment #7 also meets the described conditions.

I believe that this is fixed now (CL in comment #16), but of course we have to see if the reports stop coming.

The important part - I unfortunately missed the M54 branchpoint by just a few hours, and I think it would be worth merging this back.

The CL has passed through the first M55 Canaries. I have tried it out and I cannot reproduce the bug anymore, and I don't see any adverse effects on the history page.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

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

commit 8ce19cc272209840e306fde7485e5bc6f34432bb
Author: Martin Sramek <msramek@chromium.org>
Date: Thu Sep 01 09:07:16 2016

Make BrowsingDataHandler observe WebHistoryService deletions

BrowsingDataHandler observes local history deletions, but not synced
history deletions. In cases where there are no local history entries
to delete, it can happen that the history page does not reload and it
looks as if the deletion failed.

See https://docs.google.com/document/d/1Fd6CdBf6UMbYbkwSjEKyFOxew0Xid5IaT-QwnFchjig/
for background.

This CL
1. Adds an Observer subclass to the WebHistoryService.
2. Registers BrowsingHistoryHandler as a WebHistoryService::Observer;
   and since WebHistoryService's existence is based on whether history
   sync is enabled, we also register as a SyncServiceObserver.
3. Adds a test to browsing_history_handler_unittest.cc.

Also tested manually on Android - seems to solve the problem described
in the above mentioned document.

TBR=tsergeant@chromium.org,lshang@chromium.org,sky@chromium.org,dbeam@chromium.org
BUG= 604114 , 630164 

Review-Url: https://codereview.chromium.org/2263613002
Cr-Commit-Position: refs/heads/master@{#414679}
(cherry picked from commit d39070b1ac01776e5a3800a9ef55fe43dce74225)

Review URL: https://codereview.chromium.org/2299133002 .

Cr-Commit-Position: refs/branch-heads/2840@{#95}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/chrome/browser/ui/webui/browsing_history_handler.cc
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/chrome/browser/ui/webui/browsing_history_handler.h
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/chrome/browser/ui/webui/browsing_history_handler_unittest.cc
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/BUILD.gn
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/web_history_service.cc
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/web_history_service.h
[add] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/web_history_service_observer.h
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/test/fake_web_history_service.cc

Merged. Closing this now, feel free to reopen if this fix didn't help.

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

commit 8ce19cc272209840e306fde7485e5bc6f34432bb
Author: Martin Sramek <msramek@chromium.org>
Date: Thu Sep 01 09:07:16 2016

Make BrowsingDataHandler observe WebHistoryService deletions

BrowsingDataHandler observes local history deletions, but not synced
history deletions. In cases where there are no local history entries
to delete, it can happen that the history page does not reload and it
looks as if the deletion failed.

See https://docs.google.com/document/d/1Fd6CdBf6UMbYbkwSjEKyFOxew0Xid5IaT-QwnFchjig/
for background.

This CL
1. Adds an Observer subclass to the WebHistoryService.
2. Registers BrowsingHistoryHandler as a WebHistoryService::Observer;
   and since WebHistoryService's existence is based on whether history
   sync is enabled, we also register as a SyncServiceObserver.
3. Adds a test to browsing_history_handler_unittest.cc.

Also tested manually on Android - seems to solve the problem described
in the above mentioned document.

TBR=tsergeant@chromium.org,lshang@chromium.org,sky@chromium.org,dbeam@chromium.org
BUG= 604114 , 630164 

Review-Url: https://codereview.chromium.org/2263613002
Cr-Commit-Position: refs/heads/master@{#414679}
(cherry picked from commit d39070b1ac01776e5a3800a9ef55fe43dce74225)

Review URL: https://codereview.chromium.org/2299133002 .

Cr-Commit-Position: refs/branch-heads/2840@{#95}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/chrome/browser/ui/webui/browsing_history_handler.cc
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/chrome/browser/ui/webui/browsing_history_handler.h
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/chrome/browser/ui/webui/browsing_history_handler_unittest.cc
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/BUILD.gn
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/web_history_service.cc
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/web_history_service.h
[add] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/browser/web_history_service_observer.h
[modify] https://crrev.com/8ce19cc272209840e306fde7485e5bc6f34432bb/components/history/core/test/fake_web_history_service.cc