does this affect M55?

Indeed.

Actually, this is accounted for by the local history service at https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/browsing_history_handler.cc?sq=package:chromium&ssfr=1&l=1008 which prevents the reload if the deleted items from the history service match the deleted urls received by the handler.

This issue happens because the web history service comes along a second or two later and causes the list refresh. For now, we can just assume that any deletion message that gets received during the delete, is our delete, and not refresh the page. (https://codereview.chromium.org/2455503004/)

+msramek for web history stuff. Is it possible to do a deleted urls check for web history?

WebHistoryService response only contains "version_info", it doesn't report which rows were deleted. But I think it's enough if WebHistoryService reports to Observers which URLs were *requested* to be deleted (if the server response was positive). Then there are two scenarios.

a) A set of URLs. Compare with the set of expected URLs, if they differ, reload the history page.

Improvement: Wait for both the local history and web history callbacks so that we don't trigger reload twice.

Hack: Currently, the only thing that deletes history entries by URL is the history page. And history page always triggers both local and web deletion. So we'll always end up with no reloading or double reloading. So we can get away with simply not handling the WebHistoryObserver callback here.

b) No URLs restriction (i.e. a timerange-based deletion was requested). This definitely didn't come from the history page (probably did from CBD), so we should reload.

Improvement: Make WebHistoryService report which time range was requested. Then, simply remove all rows in the given time range by JS without reloading.

Hack: IIRC the local history database does not notify observers of deletion attempts that didn't end up deleting anything. It could instead notify observers that an empty set of URLs was deleted. The history page would handle that by always reloading (since this request cannot possibly have come from the history page). Then, we could get away with not handling the WebHistoryServiceObserver callback here either, because of the assumption that these deletions typically come from CBD which always deletes both local and web history.

I prefer that we go with the "Improvement" instead of "Hack", so that we don't have to make fragile assumptions about where deletion requests can come from.

In long term, this would be most elegantly solved if Sync reported web history changes through ProfileSyncService. My WebHistoryServiceObserver was just an attempt to quickly patch the b) scenario where history page didn't know about CBD deletions that only touched synced history.

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

commit a1ee6c76c90bfbe3cd842ac6d68cca5a6364738d
Author: calamity <calamity@chromium.org>
Date: Thu Nov 03 05:28:03 2016

[MD History] Fix deletion in heavily scrolled list.

This CL fixes an issue where results would reload when an item was
deleted in a history list that was scrolled beyond the first 'page'.
This was happening because code that refreshed the results on external
deletion was getting triggered for internal deletes due to the web
history service.

This has been fixed by disabling the reload when web history
deletions are occurring, bringing it in line with the local history
service.

BUG= 660267 ,  630164 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/a1ee6c76c90bfbe3cd842ac6d68cca5a6364738d/chrome/browser/ui/webui/browsing_history_handler.cc
[modify] https://crrev.com/a1ee6c76c90bfbe3cd842ac6d68cca5a6364738d/chrome/browser/ui/webui/browsing_history_handler.h
[modify] https://crrev.com/a1ee6c76c90bfbe3cd842ac6d68cca5a6364738d/chrome/browser/ui/webui/browsing_history_handler_unittest.cc
[modify] https://crrev.com/a1ee6c76c90bfbe3cd842ac6d68cca5a6364738d/components/history/core/browser/web_history_service.cc

calamity@: should we be requesting a merge for this?

Your change meets the bar and is auto-approved for M55 (branch: 2883)

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

commit eaf4e86ec35b1cb58dadc5dd0eff99f258412ce5
Author: Dan Beam <dbeam@chromium.org>
Date: Fri Nov 04 19:03:41 2016

[MD History] Fix deletion in heavily scrolled list.

This CL fixes an issue where results would reload when an item was
deleted in a history list that was scrolled beyond the first 'page'.
This was happening because code that refreshed the results on external
deletion was getting triggered for internal deletes due to the web
history service.

This has been fixed by disabling the reload when web history
deletions are occurring, bringing it in line with the local history
service.

BUG= 660267 ,  630164 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

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

Cr-Commit-Position: refs/branch-heads/2883@{#461}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/eaf4e86ec35b1cb58dadc5dd0eff99f258412ce5/chrome/browser/ui/webui/browsing_history_handler.cc
[modify] https://crrev.com/eaf4e86ec35b1cb58dadc5dd0eff99f258412ce5/chrome/browser/ui/webui/browsing_history_handler.h
[modify] https://crrev.com/eaf4e86ec35b1cb58dadc5dd0eff99f258412ce5/chrome/browser/ui/webui/browsing_history_handler_unittest.cc
[modify] https://crrev.com/eaf4e86ec35b1cb58dadc5dd0eff99f258412ce5/components/history/core/browser/web_history_service.cc

Tested the same on win10, mac and Linux using chrome version 55.0.2883.44 and on Cros Daisy using chrome version 55.0.2883.42/8872.45.0 - Observed no page reload on scrolling down the history page and deleting an entry.

Please find the screencast

Fix works as expected. Adding TE-Verified labels

Deleted: Recording #11.mp4 2.1 MB

	Recording #11.mp4 2.1 MB View Download