Repository navigation
Filter lists are considered out of date in incognito mode #399
Description
Prerequisites
- [x ] I verified that this is not a filter issue
- Filter issues MUST be reported at filter issue tracker
- [x ] This is not a support issue or a question
- Support issues and questions are handled at /r/uBlockOrigin
- [ x] I performed a cursory search of the issue tracker to avoid opening a duplicate issue
- Your issue may already be reported.
- I tried to reproduce the issue when...
- [x ] uBlock Origin is the only extension
- [x ] uBlock Origin with default lists/settings
- [x ] using a new, unmodified browser profile
- [x ] I am running the latest version of uBlock Origin
- [x ] I checked the documentation to understand that the issue I report is not a normal behavior
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
- Open a new browser session using Chrome
- Make sure that all Filter lists are up to date
- Open a new incognito window
- Open the Filter lists tab in the dashboard
Expected behavior:
Actual behavior:
Your environment
- uBlock Origin version: 1.18.0
- Browser Name and version: Chrome 71
- Operating System and version: Windows 10
Activity
gorhill commentedon Jan 25, 2019
Ugh... that's bad, especially finding this right after the release.
okiehsch commentedon Jan 25, 2019
That's why you do a staged rollout 😉
Firefox works fine.
gorhill commentedon Jan 25, 2019
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.gorhill commentedon Jan 25, 2019
@okiehsch Is it something that was reported elsewhere or you just stumbled on it?
okiehsch commentedon Jan 25, 2019
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.
uBlock-user commentedon Jan 25, 2019
How is it that it's only happening with this release and didn't occur before ?
gorhill commentedon Jan 25, 2019
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.
okiehsch commentedon Jan 25, 2019
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.
okiehsch commentedon Jan 25, 2019
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.
gorhill commentedon Jan 25, 2019
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.gorhill commentedon Jan 25, 2019
If using
spanningmode, the IndexedDB can be shared in incognito windows, but this causes this issue: uBlock-LLC/uBlock#1225.okiehsch commentedon Jan 25, 2019
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.
gorhill commentedon Jan 25, 2019
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.
uBlock-user commentedon Jan 25, 2019
I 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.
okiehsch commentedon Jan 25, 2019
Well, that would not be good.
okiehsch commentedon Jan 25, 2019
You have to check the filter lists tab in the incognito mode window, that is not something your average user will do.
Fix reverting use of IndexedDB as default cache storage on Chromium
funkydude commentedon Jan 26, 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).
troysjanda commentedon Jan 26, 2019
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
okiehsch commentedon Jan 26, 2019
I can't reproduce unless I enable the private browsing mode and that is - like funkydude mentioned - an old issue. gorhill/uBlock#2925 (comment)
troysjanda commentedon Jan 26, 2019
gorhill commentedon Jan 26, 2019
Of course, it needs to be said this is not really a problem since Chromium does compress storage on disk, as @gwarser noted.
Fix reverting use of IndexedDB as default cache storage on Chromium