Firefox 114 "Clear History" does not clear download history
Categories
(Firefox :: Downloads Panel, defect, P3)
Tracking
()
People
(Reporter: ceplaw, Unassigned)
Details
(Keywords: privacy, steps-wanted)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/114.0
Steps to reproduce:
Windows 11 installation, have NOT tested on any other platform:
(1) Existing, pre-114 installation of Firefox has (a) history set to 0 days, (b) "browsing and download history" checked in the Clear Recent History dialog (<ctrl><shft><del> or History | Clear Recent History). When Clear Recent History command is issued (hotkey or menu), download history is cleared.
(2) Install 114.x Firefox (64 bit Windows).
Actual results:
When Clear Recent History command is issued in Firefox 114.x, download history is NOT cleared. This has been tested with the checkbox selected, not selected, and toggled through a full cycle.
Clearing download history now requires going to the actual download history pane/popup and manually selecting "clear download history."
Expected results:
If the dialog window says that "clearing history" will also clear download history, that's what it should do. That is, in fact, what the default behavior should be.
This has persisted from 114.0 through 114.0.1 (Windows 64-bit).
A better design of that dialog would be to have SEPARATE ENTRIES for "browsing history" and "download history" in the first place. These two items SHOULD NOT be grouped for this purpose... especially when, in version 114.x, it appears that they are being processed separately under the hood. They should not, however, require separate clicks IF the user specifically chooses "When I clear my history, I want to clear BOTH my browsing history AND my download history."
This is a potential security issue that does not qualify for "being kept hidden from the public": Rather the opposite, the "public" needs to be aware of the bug so it can perform the additional work-around step of ALSO going into the download history and separately clearing it.
|
||
Comment 1•11 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•11 months ago
|
|
||
Comment 2•11 months ago
|
||
Thank you for reporting. I am sorry that you are experiencing issues. I tried reproducing this with Fx114.0.2 on both Windows 11 and MacOs and could not reproduce this. The downloads history is always properly cleared when I am testing this.
I need some more information to investigate further:
- Does this also occur for a fresh profile (on about:profiles you can create and launch a test profile) ?
- Does this also occur in Troubleshoot mode?
- Does it also not work for shutdown clearing?
- Would you be willing to share your about:support data with me? You can also send it via email to me if you are not comfortable attaching it (hpeuckmann@mozilla.com)
Regarding your suggestion to have browsing history and downloads history separated, we also think that the menu items need work and we are rethinking our labels and categories. See e.g Bug 1828617 - Improve the Clear History dialog labels and Bug 1765533 - Issues with Clear Recent History
(In reply to hpeuckmann from comment #2)
Responses interleaved below:
Thank you for reporting. I am sorry that you are experiencing issues. I tried reproducing this with Fx114.0.2 on both Windows 11 and MacOs and could not reproduce this. The downloads history is always properly cleared when I am testing this.
I need some more information to investigate further:
- Does this also occur for a fresh profile (on about:profiles you can create and launch a test profile) ?
Yes, but intermittantly. (I discontinued testing once I saw it was inconsistent and returned to my "real" profile, so there's insufficient data to point out why.)
- Does this also occur in Troubleshoot mode?
Yes, both with fresh profile (intermittantly) and "regular" profile (consistently).
- Does it also not work for shutdown clearing?
So far as I can tell, yes... but I never rely on shutdown clearing, when I shut down I then run separate batch jobs that nuke the entire cache2 hierarchy and all .sqlite files before restarting. Shutdown clearing has been grossly inadequate and unreliable since version numbers in the 30s. (It's still better than any Cr-based browser, and don't even mention Exploder; at least this process largely works!)
- Would you be willing to share your about:support data with me? You can also send it via email to me if you are not comfortable attaching it (hpeuckmann@mozilla.com)
I will create a fresh one some time in the next 48 hours and send via e-mail from the e-mail registered to this username. Due to the nature of the work I do, I have to be careful here... which is precisely my point behind suggesting that this is a security flaw of the type that needs to be publicized, not kept confidential until fixed.
Regarding your suggestion to have browsing history and downloads history separated, we also think that the menu items need work and we are rethinking our labels and categories. See e.g Bug 1828617 - Improve the Clear History dialog labels and Bug 1765533 - Issues with Clear Recent History
This is a bit frustrating/amusing because I first suggested it (under a different user name) in 2010 and was shouted down because it would be too complicated. I continue to support it, but suspect there will be substantial pushback from the we-must-enable-seamless-session-restore-in-all-circumstances-for-Reasons crowd. Again.
|
|
||
Comment 4•11 months ago
|
||
Thank you, this is helpful.
The about:support data reached me and from my perspective it does not look suspicious, which makes sense since this does seams to happen to you also with a fresh profile.
I was able to reproduce at least a similar issue, the downloads cleaner does not always remove all downloads from the downloads history, when it is not run in conjunction with the history cleaner.
Since the UI checkbox for browsing and downloads history is always triggering both cleaners, I am not sure if this is related to the issue your describing.
Could you do me another favor?
- open the browser console and run the command
await Sanitizer.sanitize(["downloads", "history"])this will (should) clear your browsing and downloads history. Please let me know if this reliably clears your downloads history or if the issue persists.
Thank you for helping me out!
(In reply to hpeuckmann from comment #4)
Thank you, this is helpful.
The about:support data reached me and from my perspective it does not look suspicious, which makes sense since this does seams to happen to you also with a fresh profile.
I was able to reproduce at least a similar issue, the downloads cleaner does not always remove all downloads from the downloads history, when it is not run in conjunction with the history cleaner.
Since the UI checkbox for browsing and downloads history is always triggering both cleaners, I am not sure if this is related to the issue your describing.
Could you do me another favor?
- open the browser console and run the command
await Sanitizer.sanitize(["downloads", "history"])this will (should) clear your browsing and downloads history. Please let me know if this reliably clears your downloads history or if the issue persists.Thank you for helping me out!
Not seeing how to run a command in the current version of the browser console (ctrl-shft-J), and that's... not a filter (gets a null result).
One really quirky side issue that may, or may not, be related:
(1) I use an external .pdf reader. (Everybody should, but that's an argument I've lost long ago. I'm sort-of over it but will continue whingeing at every opportunity; I am, however, past recruiting villagers with torches and pitchforks. Barely.)
(2) Although I have not kept logs, this particular error seems to ALWAYS occur if there's a PDF in the download history. It's barely possible that a PDF that was right-click-downloaded at some time didn't do so, but I do that only very rarely and it's impossible to tell from the user interface whether a PDF in the download history is there due to a formal download command or a must-download-to-use-the-default-external-viewer situation so I probably wouldn't have noticed anyway.
(3) Corollary: Although I have not kept logs and the sample size would be two, in my recollection this ALWAYS occurs for CSV files -- again, I force use of an external viewer. (You may have figured out by now that I do NOT treat a browser as an adequate substitute for special-purpose programs or the operating system itself.) For a sample size of one, this also occurred with a .TXT file (again, external viewer forced).
So, a possibility that should be investigated and probably ruled out (since you were able to at least partially duplicate this misbehavior): Is some interaction between "send this file type to an external viewer" and "file type in the download history" contributing to this misbehavior?
|
|
||
Comment 6•10 months ago
|
||
The severity field is not set for this bug.
:hpeuckmann, could you have a look please?
For more information, please visit BugBot documentation.
Updated to 115.0.1 and it has gotten weirder.
I had two media files in my download history, both about 75mb. Clicked the History | Clear Recent History option...
... and that removed one, but not both, of the media files from my download history. The only possible distinction between the two is that the one that was not removed was the most-recent one, and I had not flipped away from the Firefox window since that download finished. I'm starting to wonder if there's some relationship to the misbegotten/potential-security-risk "Session Restore" subsystem?
In case the initial report was not completely clear: This behavior specifically began with version 114.0; version 113.x did NOT display this behavior, and no extensions were added/updated/changed in the interim.
|
|
||
Comment 8•10 months ago
|
||
Thank you for the update CEP.
I still can not reproduce this when choosing the Clear Recent History option but I can reproduce it when running the downloads cleaner on its own.
We changed the code that is syncing the prefs for download history and browsing history, but that landed in 113 (Bug 1821042) so I don't think it is involved here.
As far as I debugged this, the sanitizer code and the clear data service don't seem to be where the error lies, instead i found that here we get an empty list although there are still items in the downloads panel.
|
|
||
Comment 9•10 months ago
|
||
Moved this to the downloads component, I think it is a better fit.
@mak, I can provide more details on how I tried to reproduce/debug if you need.
|
||
Comment 10•10 months ago
•
|
||
(In reply to CEP from comment #0)
(1) Existing, pre-114 installation of Firefox has (a) history set to 0 days
We don't have a setting to clear history at a specific amount of days. What does this mean in practice, did you check the Never Remember History option by chance? Or something else?
(b) "browsing and download history" checked in the Clear Recent History dialog (<ctrl><shft><del> or History | Clear Recent History). When Clear Recent History command is issued (hotkey or menu), download history is cleared.
Did you also enable the Clear History on Shutdown pref? (I assume not based on your previous comments)
When Clear Recent History command is issued in Firefox 114.x, download history is NOT cleared. This has been tested with the checkbox selected, not selected, and toggled through a full cycle.
Where are you looking for the downloads history: in the Download Panel on the toolbar, or in the Library window?
(In reply to CEP from comment #7)
I had two media files in my download history, both about 75mb. Clicked the History | Clear Recent History option...
What did you pick for the "Time range to clear" option in the Clear Recent History dialog?
(In reply to hpeuckmann from comment #8)
I still can not reproduce this when choosing the Clear Recent History option but I can reproduce it when running the downloads cleaner on its own.
What do you mean by the Downloads Cleaner, the Clear Downloads button in the Library window?
(In reply to hpeuckmann from comment #9)
@mak, I can provide more details on how I tried to reproduce/debug if you need.
Any kind of steps to reproduce the problem would be appreciated.
|
|
||
Updated•10 months ago
|
|
|
||
Comment 11•10 months ago
|
||
Marco, thanks for taking over.
What do you mean by the Downloads Cleaner, the Clear Downloads button in the Library window?
I mean running the sanitizer via the console in the browser toolbox like await Sanitizer.sanitize(["downloads"])
(I was looking at the downloads view in the library window)
|
Reporter | |
Comment 12•10 months ago
|
||
(In reply to Marco Bonardo [:mak] from comment #10)
responses interleaved below to avoid confusion
(In reply to CEP from comment #0)
(1) Existing, pre-114 installation of Firefox has (a) history set to 0 days
We don't have a setting to clear history at a specific amount of days. What does this mean in practice, did you check the Never Remember History option by chance? Or something else?
Yes, it is set to "never remember history." (And it still remembers history of the current session, but that's part of the fight with the "must have full session restore!" crowd that I lost fifteen years ago.)
(b) "browsing and download history" checked in the Clear Recent History dialog (<ctrl><shft><del> or History | Clear Recent History). When Clear Recent History command is issued (hotkey or menu), download history is cleared.
Did you also enable the Clear History on Shutdown pref? (I assume not based on your previous comments)
Clarification: It IS enabled, BUT I don't rely upon it (I always do the separate batch-file-based erasures).
When Clear Recent History command is issued in Firefox 114.x, download history is NOT cleared. This has been tested with the checkbox selected, not selected, and toggled through a full cycle.
Where are you looking for the downloads history: in the Download Panel on the toolbar, or in the Library window?
Both. Usually first the Download Panel (because I seldom use the Library window), but it has occurred in both.
(In reply to CEP from comment #7)
I had two media files in my download history, both about 75mb. Clicked the History | Clear Recent History option...
What did you pick for the "Time range to clear" option in the Clear Recent History dialog?
It's always set to "Everything." (And as an aside, I should be able to pick this as a default instead of having to change it every time from "Today". Again, this appears related to the impetus for "session restore.")
(In reply to hpeuckmann from comment #8)
I still can not reproduce this when choosing the Clear Recent History option but I can reproduce it when running the downloads cleaner on its own.
What do you mean by the Downloads Cleaner, the Clear Downloads button in the Library window?
Not my comment (noting this for completeness only)
(In reply to hpeuckmann from comment #9)
@mak, I can provide more details on how I tried to reproduce/debug if you need.
Any kind of steps to reproduce the problem would be appreciated.
Not my comment (noting this for completeness only)
|
|
Reporter | |
Comment 13•10 months ago
|
||
(In reply to CEP from comment #12)
Just realized I overspoke on one thing:
(In reply to Marco Bonardo [:mak] from comment #10)
responses interleaved below to avoid confusion
[snip]
(In reply to CEP from comment #7)
I had two media files in my download history, both about 75mb. Clicked the History | Clear Recent History option...
What did you pick for the "Time range to clear" option in the Clear Recent History dialog?
It's always set to "Everything." (And as an aside, I should be able to pick this as a default instead of having to change it every time from "Today". Again, this appears related to the impetus for "session restore.")
Clarification: Every time there's an update, I have to change it from "today" to "everything." That is, my choice of "everything" gets reverted whenever there's an update. As I had just updated to 115.0.1, that's where my brain was when typing this morning; the "every time" was an overstatement. (And, again, this is "sessionrestoritis")
This is a continuing problem across application programs and operating systems: The assumption that no user-selected option that is different from the defaults is immune from being silently reverted to the default by an update... and the forced reversion is not covered in the changelog, meaning that when someone uses a program bleary eyed late at night/first thing in the morning for the first time after the update, it may not be noticed. This time, I did, because I'm specifically looking for issues regarding Clearing History (thanks to this report); other times, it might have slid by, as I blithely assumed "I selected Everything three versions ago, surely THAT hasn't been changed in an update!" It's not unique to Firefox (or Thunderbird), but it's really expletive-deleted annoying and I hope Mozilla tries to be better than that.
tl;dr It's rude (insert JarJar Binks .gif here) to revert explicitly selected by the user preferences to a default in an update, and especially in a below-major-version-number update. Don't do it.
|
|
Reporter | |
Comment 14•10 months ago
|
||
Two minor progress notes:
(1) Updating to 115.0.2 reverted the "How much history to clear?" selection from user-selected "Everything" to default-setting "Today." (And one wonders why "today" is not "this session," since the choice is probably related to session restore?)
(2) The "incomplete deletion" condition in 115.0.2 has improved from "always" to "intermittent", and a second attempt now appears to clear everything — so long as I manually open the downloads list between the two attempts. This suggests to me that hpeuckmann's comment 8 is pointing toward where this particular problem lies in this particular set of code. What the problem is, though, is for others...
|
|
||
Comment 15•10 months ago
•
|
||
(In reply to CEP from comment #14)
(1) Updating to 115.0.2 reverted the "How much history to clear?" selection from user-selected "Everything" to default-setting "Today." (And one wonders why "today" is not "this session," since the choice is probably related to session restore?)
So it's possible the in some cases you inadvertently cleared Today instead of Everything, and the leftovers made you think old download were not cleared. This is not dismissing the issue, but it's maybe less common than how it was described so far.
(2) The "incomplete deletion" condition in 115.0.2 has improved from "always" to "intermittent", and a second attempt now appears to clear everything — so long as I manually open the downloads list between the two attempts. This suggests to me that hpeuckmann's comment 8 is pointing toward where this particular problem lies in this particular set of code. What the problem is, though, is for others...
Hm, I wonder if in reality downloads are cleared but the UI is not updating to reflect that.
The clear process is also asynchronous, so it may take a few seconds to complete.
The next time it happens, it would be nice if you could wait a minute, then open the history sidebar (CTRL+H) and search for somepart of the download url that was leftover (any word from the url should match). If the history sidebar returns nothing, then it's a visual problem in the downloads views to investigate. If instead the history sidebar finds something, it's a backend problem to investigate.
|
|
Reporter | |
Comment 16•10 months ago
|
||
(In reply to Marco Bonardo [:mak] from comment #15)
(In reply to CEP from comment #14)
(1) Updating to 115.0.2 reverted the "How much history to clear?" selection from user-selected "Everything" to default-setting "Today." (And one wonders why "today" is not "this session," since the choice is probably related to session restore?)
So it's possible the in some cases you inadvertently cleared Today instead of Everything, and the leftovers made you think old download were not cleared. This is not dismissing the issue, but it's maybe less common than how it was described so far.
I didn't report this as a bug until I was careful to check this every time after first noticing it and gathering data to see if I could find a problem. Your inference is reasonable, but I tried eliminating all other causes first. (As noted above, once I started noticing a problem I was checking the Time Range to Clear every time.)
(2) The "incomplete deletion" condition in 115.0.2 has improved from "always" to "intermittent", and a second attempt now appears to clear everything — so long as I manually open the downloads list between the two attempts. This suggests to me that hpeuckmann's comment 8 is pointing toward where this particular problem lies in this particular set of code. What the problem is, though, is for others...
Hm, I wonder if in reality downloads are cleared but the UI is not updating to reflect that.
The clear process is also asynchronous, so it may take a few seconds to complete.
I would expect this to be most likely when clearing a lot of history/lots of downloads, but I clear both at least twice a day on a reasonably fast machine (i5, 16gb, SSD, not many other programs running). And before you ask, I've nuked the profile several times and minimized extensions during this process, too, to no apparent effect.
The next time it happens, it would be nice if you could wait a minute, then open the history sidebar (CTRL+H) and search for somepart of the download url that was leftover (any word from the url should match). If the history sidebar returns nothing, then it's a visual problem in the downloads views to investigate. If instead the history sidebar finds something, it's a backend problem to investigate.
I'll try that next time I spot the error, but I would raise a Mr Spock eyebrow at it, having never encountered that phenomenon before...
|
|
Reporter | |
Comment 17•10 months ago
|
||
(In reply to CEP from comment #16)
(In reply to Marco Bonardo [:mak] from comment #15)
[snip]The next time it happens, it would be nice if you could wait a minute, then open the history sidebar (CTRL+H) and search for somepart of the download url that was leftover (any word from the url should match). If the history sidebar returns nothing, then it's a visual problem in the downloads views to investigate. If instead the history sidebar finds something, it's a backend problem to investigate.
I'll try that next time I spot the error, but I would raise a Mr Spock eyebrow at it, having never encountered that phenomenon before...
Three instances over the last few days. After waiting 60 seconds each time, searching the history sidebar did NOT return a match. This seems to confirm your inference that it may be "a visual problem in the downloads view to investigate."
But due to my other settings, searching the history sidebar is dubious in the first place. This appears, again, to be a conflict between "history retained on the machine, set to never retain history" and "session restore capability," the latter of which cannot be turned off (apparently) even if I chose to. (Public machines, like those at libraries, certainly should be able to fully nuke any session restore capability!)
|
|
||
Comment 18•10 months ago
|
||
The severity field is not set for this bug.
:mak, could you have a look please?
For more information, please visit BugBot documentation.
|
|
||
Comment 19•9 months ago
|
||
Confirming as a privacy bug, even if the problem is just visual, it doesn't give good feelings.
The intermittent nature of the bug may not make it easy to debug though, so finding better steps to reach the unexpected status starting from a clean profile would help a lot.
|
|
Reporter | |
Comment 20•7 months ago
|
||
(In reply to Marco Bonardo [:mak] from comment #19)
Confirming as a privacy bug, even if the problem is just visual, it doesn't give good feelings.
The intermittent nature of the bug may not make it easy to debug though, so finding better steps to reach the unexpected status starting from a clean profile would help a lot.
Although I haven't found "better steps" (or other steps), I have confirmed that the steps in the original report also cause the unexpected status in a clean profile (but time range to clear manually set to "everything") on a brand-new machine I was setting up for a client.
Description
•