Repository navigation
Filter lists are considered out of date in incognito mode #399
Description
Activity
Ugh... that's bad, especially finding this right after the release.
- addedbugSomething isn't workingSomething isn't workingChromiumspecific to Chromium/Chromespecific to Chromium/Chrome
on Jan 25, 2019 That's why you do a staged rollout 😉
Firefox works fine.Currently the stage is 6% of 10,000,000+, not good.
Especially that there is no easy solution for this. I can fix it by removing
"incognito": "split"in the manifest, but then the "document blocked" page can no longer be loaded in incognito mode. The only fix possible is to remove support for IndexedDB, hence support for compression.Reacted by Navin Francis Shajan@okiehsch Is it something that was reported elsewhere or you just stumbled on it?
I stumbled on it, I only used the dev version with Firefox, so today was the first time that I used 1.18.0 with my laptop.
How is it that it's only happening with this release and didn't occur before ?
How do you conclude it did not occur before? I am sure it did occur, it just happened nobody stumbled on it. I don't use incognito myself, Chromium is not my main browser, I just test/debug uBO with it.
I meant that I only used the dev version with Chrome to check for some obvious bugs concerning the logger and such.
I always used the stable/Chromium version with my productive setups.The filter lists are not really out of date and the users will have the newest filters, so technically it is not a big deal but there will be complaints.
The filter lists are not really out of date
I am sure they are out of date, Chromium is creating a whole new IndexedDB for the incognito process of uBO. I have no choice but to revert back to
chrome.storage.local-- which is a trivial fix in itself but we now lose LZ4 compression in Chromium. With non-trivial work I could support LZ4 forchrome.storage.localbut not sure this will be worth it efficiency-wise.Reacted by bb010gIf using
spanningmode, the IndexedDB can be shared in incognito windows, but this causes this issue: uBlock-LLC/uBlock#1225.I am sure they are out of date
I see, so the filter list version of the incognito window would always be the one of the time I opened the new browser session.
It would be the lists from the package, or there would be a fetch to a remote server for the ones selected which are not in the package.
Reacted by okiehschI didn't conclude anything, nobody reported it so I assumed something like this didn't happen before, hence my question, given it's this serious, I'm surprised nobody saw this, means incognito is not used as much as I thought.
If using spanning mode, the IndexedDB can be shared in incognito windows, but this causes this issue: uBlock-LLC/uBlock#1225.
Instead, they receive a Chrome error page with ERR_ADDRESS_UNREACHABLE.Well, that would not be good.
I'm surprised nobody saw this, means incognito is not used as much as I thought.
You have to check the filter lists tab in the incognito mode window, that is not something your average user will do.
- added a commit that references this issue
on Jan 25, 2019 Just wanted to add that a similar issue happens with Firefox.
Whilst opening a standard incognito window works fine, enabling it permanently breaks updating the lists.

Enable "always use..." and it will ask you to relaunch the browser.
That's when the lists are broken.
It will display less entries than it normally would, as if it falls back to preinstalled defaults.
Some will be marked as out of date, and clicking update won't change the counter.edit: Just wanted to add that this is quite an old issue (in Firefox).
I am getting this as well on the latest RC with FF64.0.2 on Windows 10 Ent, The filter will not update even if you select update, it goes through the update and seem like it did but no changes to the count numbers. Also if you close and open FF there ware update to be done. I selected purge and then update let it finish and close and reopen FF and have to do it all again. was not happening b4 update to 1.18.1rc1
I can't reproduce unless I enable the private browsing mode and that is - like funkydude mentioned - an old issue. gorhill/uBlock#2925 (comment)
- Not an old issue! and I am having the issue as described without using incognito mode. I had to uninstall ff and reinstall to fix issue
we now lose LZ4 compression in Chromium
Of course, it needs to be said this is not really a problem since Chromium does compress storage on disk, as @gwarser noted.
- added a commit that references this issue
on Jul 16, 2026
Prerequisites
Description
Filter lists are always considered out of date if you open a new incognito mode window in Chrome.
Worked fine with 1.17.4
Steps to Reproduce
Expected behavior:
Actual behavior:
Your environment