localhost: breakage

[pmitros]

Prerequisites

• I read and understood the policy as to what is a valid filter issue
• I verified that the issue has not already been reported (use this button to find out)
• I forced an update of my filter lists (how to do this: click "Purge all caches", then click "Update now")
• I did not remove any of the default filter lists
• I have no custom filter lists, or I verified that the issue still occurs without custom filter lists
• I am not using another content blocker along uBO

URL address of the web page

http://localhost:8888/

Category

breakage

Describe the issue

uBlock Origin will block:

/static/3rd_party/d3.v5.min.js
/static/3rd_party/require.js

Both on localhost:8888. This is the safest thing in the world. These are standard libraries, and not using a CDN preserves privacy.

I'm pretty sure these weren't blocked until recently.

Screenshot(s)

Screenshot(s)

Configuration

uBlock Origin: 1.40.0
Firefox: 95
filterset (summary): 
  network: 78235
  cosmetic: 40066
  scriptlet: 16375
  html: 608
listset (total-discarded, last updated): 
  default: 
    ublock-filters: 30597-30, 1d.22h.45m
    ublock-badware: 3513-1, 1d.22h.43m
    ublock-privacy: 180-0, 1d.22h.41m
    ublock-abuse: 81-0, 1d.22h.39m
    ublock-unbreak: 1712-0, 1d.22h.37m
    easylist: 62197-565, 1d.22h.35m
    easyprivacy: 26543-475, 1d.22h.33m
    urlhaus-1: 7994-0, 11h.37m
    plowe-0: 3687-3, 12d.2h.17m
filterset (user): [empty]
modifiedUserSettings: [none]
modifiedHiddenSettings: [none]
supportStats: 
  launchToReadiness: 278 ms (selfie)
popupPanel: 
  blocked: 2

[gorhill]

This is the safest thing in the world.

Just disable uBO for localhost.

[pmitros]

Sure. It's not rocket science to work around, but it's still a bug. If it's not worth fixing, just close the issue.

[gorhill]

Look at the logger to find out what filters from which filter lists cause this, report your findings.

[pmitros]

Okay. This is a total Heisenbug. The page loads fine now.

However, this originally came up reloading from a terminated Firefox. I can still reliably replicate the issue by:

1. Killling Firefox (ctrl-C, or kill -9)
2. Restarting Firefox, restoring pages

The rule being triggered is:

*$script,1p,domain=~kat.ec|~kat.eu|~kat.mn|~kat.rip|~kat.tv|~kickass.website|bigkickass.*|kat.*|kat2.*|katbay.*|katfreak.*|kathydra.*|katkickass.*|katkickass.*|kattracker.*|kick4ss.*|kickass-usa.*|kickass.*|kickass2.*|kickassaustralia.*|kickassbay.*|kickassdb.*|kickassfull.*|kickassgo.*|kickasshydra.*|kickassindia.*|kickasskat.*|kickassminds.*|kickassmovies.*|kickasspk.*|kickasst.*|kickasstorrents.*|kickasstorrents2.*|kickasstracker.*|kickasstrusty.*|kickassuk.*|kickassunlocked.*|kickassz.*|kkat.*|kkickass.*|thekat.*|thekickass.*|topkickass.*|torrentkat.*|torrentskickass.*

When I first reported the issue, refreshing the page in Firefox didn't help; it only started loading when I disabled uBO and refreshed.

Now, it consistently triggers on that rule if restoring from a killed Firefox. However, if I refresh, the page comes up fine.

Weird.

[pmitros]

This is what it looks like in the logger.

[gorhill]

this originally came up reloading from a terminated Firefox

That filter shouldn't trigger for localhost, I suspect a corrupted storage. Force an update of all filter lists.

[pmitros]

I had done that before filing the ticket (it was one of the checkboxes). I just did it again. It reproduces.

[gwarser]

uBlock Origin: 1.40.0
Firefox: 95
filterset (summary): 
  network: 79689
  cosmetic: 47400
  scriptlet: 16573
  html: 619
listset (total-discarded, last updated): 
  default: 
    ublock-filters: 30596-72, 2d.19h.54m
    ublock-badware: 3626-1, 2d.19h.52m
    ublock-privacy: 180-0, 2d.19h.50m
    ublock-abuse: 81-0, 2d.19h.48m
    ublock-unbreak: 1689-0, 2d.19h.46m
    easylist: 62159-580, 2d.19h.44m
    easyprivacy: 26545-483, 2d.19h.42m
    urlhaus-1: 7994-0, 22h.36m
    plowe-0: 3717-3, 2d.19h.38m
    POL-0: 7751-25, 22h.36m
    POL-2: 1265-9, 22h.36m
filterset (user): [empty]
switchRuleset: 
  added: [array of 1 redacted]
modifiedUserSettings: [none]
modifiedHiddenSettings: [none]
supportStats: 
  launchToReadiness: 135 ms (selfie)

Simple html and two scripts in subfolder + shell script to run Python local server:
Server-fixed.zip

[gwarser]

After purging with Shift and updating:

[gwarser]

[rdk@on uBlock-git]$ git bisect good && make firefox
e45d851f66dbbd0a1c41d0b724779b3cb3058c4d is the first bad commit
commit e45d851f66dbbd0a1c41d0b724779b3cb3058c4d
Author: Raymond Hill <rhill@raymondhill.net>
Date:   Sat Dec 18 12:53:09 2021 -0500

    Store `domain=` option into trie container's character buffer
    
    As the trie is not immediately created, in order to speed up
    launch time, the `domain=` option was stored in the filterRefs
    array until it was moved to the trie.
    
    This commit instead stores the `domain=` option into the trie
    container's character buffer.

 src/js/background.js           |  2 +-
 src/js/hntrie.js               | 70 +++++++++++++++++++++++++++++---
 src/js/static-net-filtering.js | 92 +++++++++++++++++++-----------------------
 3 files changed, 107 insertions(+), 57 deletions(-)
make: Nothing to be done for 'firefox'.
[rdk@on uBlock-git]$ 

[gorhill]

I was able to reproduce using only these two filters and all other filter lists disabled:

/^/$script,domain=example.*|bar.*
.js|$script,domain=foo.*|bar.*

The two filters were needed to reproduce, I wasn't able to reproduce with only one or the other.

[gorhill]

Until the fix is published in 1.40.2, a workaround which should work is to visit another site, for example https://example.org, then reload the localhost page.

[pmitros]

Thank you for the super-quick fix! That was impressive.