Filter lists are considered out of date in incognito mode

[okiehsch]

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

1. Open a new browser session using Chrome
2. Make sure that all Filter lists are up to date
3. Open a new incognito window
4. 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

[gorhill]

Ugh... that's bad, especially finding this right after the release.

[okiehsch]

That's why you do a staged rollout 😉
Firefox works fine.

[gorhill]

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]

@okiehsch Is it something that was reported elsewhere or you just stumbled on it?

[okiehsch]

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]

How is it that it's only happening with this release and didn't occur before ?

[gorhill]

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]

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]

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]

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 for chrome.storage.local but not sure this will be worth it efficiency-wise.

[gorhill]

If using spanning mode, the IndexedDB can be shared in incognito windows, but this causes this issue: uBlock-LLC/uBlock#1225.

[okiehsch]

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.

[gorhill]

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]

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]

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.

[okiehsch]

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.

[funkydude]

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]

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]

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]

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

[gorhill]

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.

[gwarser]

https://github.com/uBlockOrigin/uBlock-issues/wiki/Advanced-settings/_compare/991dfe766a94f6f5d72590250547f90783cb8ad0