New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 395955 link

Starred by 39 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 3
Type: Bug

issue 474511

Sign in to add a comment

Call to `chrome.history.deleteUrl` does not affect synced history

Reported by, Jul 22 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Steps to reproduce the problem:
1. Create extension that removes all visits from history as they are added (example attached)
2. Sign in to Google with Chrome and configure history sync
3. Visit any site, see that extension background page logs visit removal
4. Open chrome://history and see that no visits were actually removed
5. Go to Chrome settings and disable history sync
6. Repeat 3, see that history is properly removed

What is the expected behavior?
`chrome.history.deleteUrl` removes url from history no matter if history sync enabled or not.

What went wrong?
Call to `chrome.history.deleteUrl` with history sync enabled does nothing.
See steps to reproduce and attached extension code.

Did this work before? N/A 

Chrome version: 36.0.1985.125  Channel: stable
OS Version: OS X 10.9.3
Flash Version: Shockwave Flash 14.0 r0
6.3 KB Download

Comment 1 by, Jul 24 2014

Labels: Cr-UI-Browser-History Cr-Privacy
Balazs, could you take a look at this, please?
Status: Assigned

Comment 3 by, Jul 29 2014

Status: Started
The problem here is that the HistoryDeleteUrlFunction implementation is only modifying the local history data itself, not that of any synced devices or the web history. It might make sense to move the code in the BrowsingHistoryHandler::HandleRemoveVisits into the HistoryService so as to make sure that all calls to DeleteUrl (and company) also trigger sync/web history deletes.

I will take a look.

Comment 4 by, Nov 29 2014

 Issue 436492  has been merged into this issue.

Comment 5 by, Nov 29 2014

Labels: -OS-Mac OS-All Cr-Platform-Extensions
engedy@ What is the status of this bug?
Owner: ----
Status: Available
I am sorry, I haven't been able to make further progress on this, and will probably not have time to do so before the end of the year. I can probably take a look in January. Until then, I will un-assign the CL.
Just wanted to confirm this 'bug'. I just wrote an extension that calls deleteUrl(), and on an instance that has history sync enabled, it removes the entry from the 'recently visited' dropdown on OSX Chrome, but the chrome://history page still has the deleted entry.

Wanted to add to this, I feel like the extension history API should interface with synced history when syncing is turned on. If `chrome.history.deleteUrl` is changed to modify synced history then I feel like `` should be modified to search against synced history. 

The behavior of the history API is very odd when syncing is enabled. I have a history override extension that is basically broken when syncing is enabled for a user.
Blocking: chromium:474511
Yes, it sounds reasonable to address this limitation for all methods once somebody gets around to fix the deletion, as it is probably not much work after that. I have filed  Issue 474511  to document this.
zea@ - seems like we're not syncing the change from the history API, if this bug is still relevant. It uses HistoryService::DeleteURL: - using the wrong thing, I suppose?

Comment 12 by, Apr 10 2015

Well, I think DeleteURL is the right one to call, but it needs to be modified to behave more like BrowsingHistoryHandler::HandleRemoveVisits. That said, I'm not too familiar with the history code.
Eh, what a PITA, looks like the sync behavior is implemented all in webui. I'd need to spend some time with that code, but I notice davidben's name around there. Perhaps it should actually use HistoryService::ExpireLocalAndRemoteHistoryBetween (with the "between" from negative to positive infinity).
I don't really know anything about HistoryService. Apparently I fixed a shutdown crash in it more than a year ago, but I don't remember anything about that code.
I can still reproduce this in "Chrome (not Chromium) stable Version 48.0.2564.97 (64-bit)"...

Here is a gif of me reproducing it:

Here is the code for the extension I'm using:

Comment 16 by, Mar 18 2016

Still have the problem. Chrome version: Version 49.0.2623.87 m. OS: Windows 7.

In my case a user confirms that he want to remove some particular entries from his history.
Still have the problem on Chrome version 54.0.2840.100 (64-bit), linux
Still confirmed on 54.0.2840.99 m on Windows as well.  
Still have the problem.
Chrome version 56.0.2924.87 (64-bit)
Windows 10 & 7
Sorry to bug you guys, but this bug needs attention of Chrome team.
Still confirmed broken v63.0.3239.84

Deletes from local history but still in chrome://history because it doesn't delete synced history :(
Labels: SyncHandoff2018
 Issue 402259  has been merged into this issue.
Labels: Hotlist-Privacy

Comment 26 by, Feb 27 2018

 Issue 474511  has been merged into this issue.

Comment 27 by, Feb 27 2018

Labels: -Pri-2 -OS-All OS-Chrome OS-Linux OS-Mac OS-Windows Pri-3
Summary: Call to `chrome.history.deleteUrl` does not affect synced history (was: Call to `chrome.history.deleteUrl` with history sync enabled does nothing)
Labels: Hotlist-GoodFirstBug
Is there any progress on this issue, the bug still exists in a current extension I am using. BTW How can I contribute in solving this bug.
No progress yet, the bug is still available.

If you'd like to contribute, please see for instructions on how to fetch and compile Chromium code (though keep in mind that it's not a small project, size-wise as well as compile time-wise).

The code to start looking at is in
 Issue 917671  has been merged into this issue.
Took a very quick browsing of that code.
Looks like it should be an easy fix for a person familiar with this code.
(Note: This may be very wrong).
The sync thread/code isn't getting notified about the url deletion. The history code lacks consistency. I thought that was enforced?! The code is starting to collapse over its own weight. This is how it starts.

Sign in to add a comment