Open Bug 1380445 Opened 2 years ago Updated 7 months ago

removeDownloads method of browsingData API does not work as intendded.


(WebExtensions :: General, defect, P3)



(Not tracked)


(Reporter: shatur, Unassigned)


(Whiteboard: [browsingData]triaged)

Steps to reproduce:
1). Load forget-it example of webextension [1].
2). Set prefrences from option page to remove downloads items with certain time frame.
3). Click remove icon on toolbar.

Expected Results:
Downloads history should be removed within the specified time frame.

Actual Results:
It only removes items from the list, which is shown by toolbar download shortcut. And actual-list[list shown by "Show all downloads"] remains intact.

Thanks Tushar. I have triaged this as a P2, but not assigned it to anyone. If you would like to investigate it and see if you can fix it that would be welcome.
Priority: -- → P2
Whiteboard: [browsingData]triaged
What os or platform are you testing on? I can't reproduce on Nightly on Windows.
One thing I forgot to mention is to uncheck the history checkbox in options page. I reproduced this behavior on ubuntu and windows.
I look into it once again and I notice that downloads-history is removed only when history checkbox is checked. So, I wrote another addon which only removes history using removeHistory method and noticed that along with browsing history, download history is also being removed , which should not be happening.

The actual behavior should be: 
1). When we remove history, it should only remove browsing history items and not download history.
2). When we remove download history, it should remove it from both, list shown by toolbar download shortcut and as well as list shown by "Show all Downloads".

And I looked into the code, code related to web-extension side looks sane and I don't think the problem resides there. As aswan also suggested on irc, the problem may be in Sanitizer's code, which we use to remove items in our implementation.
Looking a little more closely, it is not so clear that this is a Sanitizer.jsm problem.  First some background: Firefox has an in-memory structure where it maintains information about downloads that took place in the current session, and it remembers older downloads in the places (history) database.  The downloads front-end UI merges these two lists so users aren't aware of this implementation detail.
When Sanitizer is asked to clear downloads, it only removes items from the in-memory structure, it does not try to find and remove downloads from the history database.  The main in-tree application of Sanitizer is for clearing data at the end of a browsing session, for which we don't provide a separate user-visible option for downloads.  There is also the "panic" button, but that is hard-coded to remove a set of types that includes both downloads and history.
So, Sanitizer.jsm has unexpected behavior when clearing downloads but other users of Sanitizer.jsm already work with the quirks.

The obvious options to me are either:
1. document the current behavior
2. enhance either Sanitizer.jsm or ext-browsingData.js to also manipulate the places database when downloads are being cleared

I'm wary of anything related to the places database but Bob, you have experience with both places and browsingData, what do you think?
Flags: needinfo?(bob.silverberg)
Thanks for looking into it, Andrew. 

I don't think we should just document the current behaviour as it is not consistent with Chrome's behaviour so it should be fixed.

Addressing it in Santizer.jsm does seem like a good idea, but we'd need to be careful about the expectations that other consumers currently have. We should audit other consumers to see how they would be impacted and how we can mitigate that. I agree that we want to avoid working with the places database directly. I would have thought that there would be other code in the tree already for removing places-stored downloads which we can use, so work on this bug should include looking for something like that.
Flags: needinfo?(bob.silverberg)
Priority: P2 → P3
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.