Skip to content

Firefox backward/forward cache broken by generic permissions policy injection #3576

Description

@feefvonheef

Prerequisites

  • I verified that this is not a filter list issue. Report any issues with filter lists or broken website functionality in the uAssets issue tracker.
  • This is NOT a YouTube, Facebook or Twitch report. These sites MUST be reported by clicking their respective links.
  • This is not a support issue or a question. For support, questions, or help, visit /r/uBlockOrigin.
  • I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
  • The issue is not present after disabling uBO in the browser.
  • I checked the documentation to understand that the issue I am reporting is not normal behavior.

I tried to reproduce the issue when...

  • uBO is the only extension.
  • uBO uses default lists and settings.
  • using a new, unmodified browser profile.

Description

Summary:

  • Generic PP injection using $permissions breaks the bfcache of Firefox.
  • This issue is not a filterlist issue, but concerns the question whether filterlists should really have the power to disable the bfcache of the user's browser for every site.
  • It seems that every uBlock Origin user on Firefox who has the AdGuard - Popup Overlays filterlist currently enabled has a broken bfcache. Furthermore: Any filterlist could introduce a generic $permissions filter anytime in the future, and thus break the bfcache for every user.

Cursory look at current filterlists:

  • OK: The uBlock filters - Privacy filterlist uses $permissions, but only restricted to localhost etc. on Chromium.
  • OK: The uBlock filters - Unbreak filterlist uses $permissions, but only for 1 domain.
  • OK: The Adguard Tracking Protection filterlist uses $permissions, but only for 2 domains.
  • Bad: The AdGuard - Popup Overlays filterlist uses $permissions for generic PP injection on any domain.

The specific location of the generic PP injection in the AdGuard - Popup Overlays filterlist can be found here, first introduced in this commit.

Workarounds:

  • Set cacheControlForFirefox1376932 to unset (using no-cache results in working bfcache by using forward/backward buttons, but broken bfcache by clicking with the left mouse button on links/images).
  • User can currently disable the AdGuard - Popup Overlays filterlist, but any filterlist could reintroduce this behavior at any moment.

Personal (half-baked) ideas:

  • Ignore generic $permission filters from filterlists? or
  • Introduce additional cacheControl flag (similar to cacheControlForFirefox1376932) for generic $permission filters, defaulting to the unset behavior?
  • Generic CSP injection has the same issue, so treat it the same way?
  • Could not reproduce the issue with generic HTTP header filters...

Related:
Interesting comments in source of traffic.js
#229
#2714

A specific URL where the issue occurs.

https://commons.wikimedia.org/wiki/File:Nature_of_Uckermark_(50818474551).jpg

Steps to Reproduce

  1. Add $permissions=something=() to custom filters, or enable current AdGuard - Popup Overlays filterlist.
  2. Restart Firefox.
  3. Go to: https://commons.wikimedia.org/wiki/File:Nature_of_Uckermark_(50818474551).jpg
  4. Click on the image. Wait for image to load.
  5. Hit back button.
  6. Click on the image again (do not use forward button). Observe that image is not cached, but reloads slowly.
  7. Hit back button + click on image a couple of times. Observe that the image reloads slowly every time.
  8. Revert previous changes and restart Firefox.
  9. Click on image. Wait for image to load. Hit back button + click on image a couple of times. Observe that the image is cached.

Expected behavior

The image will load from the cache.

Actual behavior

The image does not load from the cache.

uBO version

1.62.0

Browser name and version

Firefox 136.0.1

Operating System and version

Beyond Linux From Scratch, Windows 10

Activity

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

    Firefoxspecific to FirefoxbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions