Skip to content

Filter lists are considered out of date in incognito mode #399

Description

@okiehsch

Prerequisites

  • [x ] I verified that this is not a filter issue
  • [x ] This is not a support issue or a question
  • [ 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:

image

Actual behavior:

image

Your environment

  • uBlock Origin version: 1.18.0
  • Browser Name and version: Chrome 71
  • Operating System and version: Windows 10

Activity

  1. gorhill commented on Jan 25, 2019

    @gorhill
    Member

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

  2. added
    bugSomething isn't working
    Chromiumspecific to Chromium/Chrome
    on Jan 25, 2019
  3. okiehsch commented on Jan 25, 2019

    @okiehsch
    Author

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

  4. gorhill commented on Jan 25, 2019

    @gorhill
    Member

    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.

  5. gorhill commented on Jan 25, 2019

    @gorhill
    Member

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

  6. okiehsch commented on Jan 25, 2019

    @okiehsch
    Author

    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.

  7. uBlock-user commented on Jan 25, 2019

    @uBlock-user
    Member

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

  8. gorhill commented on Jan 25, 2019

    @gorhill
    Member

    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.

  9. okiehsch commented on Jan 25, 2019

    @okiehsch
    Author

    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.

  10. okiehsch commented on Jan 25, 2019

    @okiehsch
    Author

    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.

  11. gorhill commented on Jan 25, 2019

    @gorhill
    Member

    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.

  12. gorhill commented on Jan 25, 2019

    @gorhill
    Member

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

  13. okiehsch commented on Jan 25, 2019

    @okiehsch
    Author

    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.

  14. gorhill commented on Jan 25, 2019

    @gorhill
    Member

    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.

  15. uBlock-user commented on Jan 25, 2019

    @uBlock-user
    Member

    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.

  16. okiehsch commented on Jan 25, 2019

    @okiehsch
    Author

    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.

  17. okiehsch commented on Jan 25, 2019

    @okiehsch
    Author

    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.

  18. funkydude commented on Jan 26, 2019

    @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.
    image

    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).

  19. troysjanda commented on Jan 26, 2019

    @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

  20. okiehsch commented on Jan 26, 2019

    @okiehsch
    Author

    I can't reproduce unless I enable the private browsing mode and that is - like funkydude mentioned - an old issue. gorhill/uBlock#2925 (comment)

  21. troysjanda commented on Jan 26, 2019

    @troysjanda
  22. gorhill commented on Jan 26, 2019

    @gorhill
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Chromiumspecific to Chromium/ChromebugSomething isn't workingfixedissue has been addressed

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions