Local storage issues #917

Open
opened 2025-11-09 10:01:51 -06:00 by GiteaMirror · 0 comments
Owner

Originally created by @loldev69 on GitHub (Jul 25, 2025).

bug description

The following were tested on Chrome-based browsers and under Windows.
In both cases, local storage keeps growing without any sort of notice to the user.

Issue 1

Local storage is not cleared properly, not even when using the "clear cache" buttons under advanced settings.
Steps to reproduce:

  1. Download anything from any service that uses the processing queue.
  2. Notice how the download takes up space in the %appdata% browser folder, somewhere under \User Data\Default\File System
  3. Delete the download from the queue.
  4. Notice how the download still takes up space on disk.
  5. Use the "clear cache" button under advanced settings
  6. Notice how the download still takes up space on disk.
  7. Delete all site data for cobalt.tools either from the browser's settings or the browser's dev console.
  8. Notice how only then the download is deleted from disk.

Issue 2

Downloaded files that fail halfway through not only remain in local storage instead of being cleared out, but somehow are no longer recognized as belonging to cobalt.tools by the browser.
The only way to delete them is to delete ALL local data the browser stores for all sites.
Steps to reproduce:

  1. Download anything from any service that uses the processing queue and fails halfway through often.
  2. Have the download fail halfway through.
  3. Notice how the failed download takes up space in the %appdata% browser folder, somewhere under \User Data\Default\File System
  4. Notice how the failed download does not take up space in the site data according to the browser.
  5. Clear all site data for cobalt.tools either from the browser's settings or the browser's dev console.
  6. Notice how the download still takes up space on disk.

reproduction steps

See above

screenshots

No response


platform information

Latest Chrome, Edge and Brave on Win 10 and 11 (VMs)

additional context

No response

Originally created by @loldev69 on GitHub (Jul 25, 2025). ### bug description The following were tested on Chrome-based browsers and under Windows. In both cases, local storage keeps growing without any sort of notice to the user. ### Issue 1 Local storage is not cleared properly, not even when using the "clear cache" buttons under advanced settings. Steps to reproduce: 1. Download anything from any service that uses the processing queue. 2. Notice how the download takes up space in the %appdata% browser folder, somewhere under \User Data\Default\File System 3. Delete the download from the queue. 4. Notice how the download still takes up space on disk. 5. Use the "clear cache" button under advanced settings 6. Notice how the download still takes up space on disk. 7. Delete all site data for cobalt.tools either from the browser's settings or the browser's dev console. 8. Notice how only then the download is deleted from disk. ### Issue 2 Downloaded files that fail halfway through not only remain in local storage instead of being cleared out, but somehow are no longer recognized as belonging to cobalt.tools by the browser. The only way to delete them is to delete ALL local data the browser stores for all sites. Steps to reproduce: 1. Download anything from any service that uses the processing queue and fails halfway through often. 2. Have the download fail halfway through. 3. Notice how the failed download takes up space in the %appdata% browser folder, somewhere under \User Data\Default\File System 4. Notice how the failed download does not take up space in the site data according to the browser. 5. Clear all site data for cobalt.tools either from the browser's settings or the browser's dev console. 6. Notice how the download still takes up space on disk. ### reproduction steps See above ### screenshots _No response_ ### links ```shell ``` ### platform information Latest Chrome, Edge and Brave on Win 10 and 11 (VMs) ### additional context _No response_
GiteaMirror added the bug label 2025-11-09 10:01:51 -06:00
Sign in to join this conversation.