You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
If filters are specified via managed storage, restoreAdminSettings() calls saveUserFilters() and attempts to remove compiled user filters from the asset cache. This happens prior to cacheStorage.select(), meaning the wrong backend may be used to initialize the asset cache.
The problem occurs when both
adminSettings.userFilters or toOverwrite.filters is set in managed storage
the cache backend changes when cacheStorage.select() is called
occurs with default settings on Firefox on 1.56.0 (hardcoded switch to indexedDB)
occurs due to cacheStorageAPI setting on 1.56.1rc0 and beyond (after cache storage redesign)
I intended to open PRs but was unable due to access restrictions:
Wait at least 2 min for filter lists to update, selfie to be created
Restart Firefox and observe baseline startup behavior:
14:16:03.319 [uBO] Start sequence of loading storage-based data 23 ms after launch console.js:38:13
14:16:03.319 [uBO] Admin settings ready 35 ms after launch console.js:38:13
14:16:03.321 [uBO] Backend storage for cache will be indexedDB console.js:38:13
14:16:03.321 [uBO] Hidden settings ready 43 ms after launch console.js:38:13
14:16:03.322 [uBO] WASM modules ready 44 ms after launch console.js:38:13
14:16:03.323 [uBO] Extra admin settings ready 44 ms after launch console.js:38:13
14:16:03.326 [uBO] List selection ready 47 ms after launch console.js:38:13
14:16:03.327 [uBO] Cache magic numbers ready 48 ms after launch console.js:38:13
14:16:03.327 [uBO] WASM PSL ready 48 ms after launch console.js:38:13
14:16:03.328 [uBO] First fetch ready 50 ms after launch console.js:38:13
14:16:03.333 [uBO] PSL ready 54 ms after launch console.js:38:13
14:16:03.333 [uBO] User settings ready 54 ms after launch console.js:38:13
14:16:03.435 [uBO] Selfie ready 156 ms after launch console.js:38:13
14:16:03.437 [uBO] All ready 158 ms (selfie) after launch console.js:38:13
Note that further restarts result in similar behavior
Create ~/.mozilla/managed-storage/uBlock0\@raymondhill.net.json with contents:
Restart Firefox once and observe similar behavior again (managed storage settings are cached internally and require two restarts to take effect)
Restart Firefox again and observe that selfie is not used, loading takes significantly longer, updater starts after 15s, etc.:
14:18:19.281 [uBO] Start sequence of loading storage-based data 23 ms after launch console.js:38:13
14:18:19.281 [uBO] Admin settings ready 34 ms after launch console.js:38:13
14:18:19.282 [uBO] Backend storage for cache will be indexedDB console.js:38:13
14:18:19.282 [uBO] Hidden settings ready 41 ms after launch console.js:38:13
14:18:19.284 [uBO] WASM modules ready 42 ms after launch console.js:38:13
14:18:19.284 [uBO] Extra admin settings ready 43 ms after launch console.js:38:13
14:18:19.290 [uBO] List selection ready 48 ms after launch console.js:38:13
14:18:19.291 [uBO] Cache magic numbers ready 49 ms after launch console.js:38:13
14:18:19.291 [uBO] WASM PSL ready 50 ms after launch console.js:38:13
14:18:19.293 [uBO] First fetch ready 51 ms after launch console.js:38:13
14:18:19.297 [uBO] User settings ready 56 ms after launch console.js:38:13
14:18:19.343 [uBO] PSL ready 102 ms after launch console.js:38:13
14:18:19.389 [uBO] loadFilterLists() Start console.js:38:13
14:18:19.406 [uBO] loadFilterLists() Redirects/scriptlets ready at 16 ms console.js:38:13
14:18:19.543 [uBO] loadFilterLists() All filters removed at 154 ms console.js:38:13
14:18:19.546 [uBO] loadFilterLists() Loading filters from user-filters at 157 ms console.js:38:13
14:18:19.576 [uBO] loadFilterLists() Loading filters from ublock-privacy at 186 ms console.js:38:13
14:18:19.588 [uBO] loadFilterLists() Loading filters from ublock-quick-fixes at 199 ms console.js:38:13
14:18:19.613 [uBO] loadFilterLists() Loading filters from ublock-badware at 223 ms console.js:38:13
14:18:19.631 [uBO] loadFilterLists() Loading filters from plowe-0 at 242 ms console.js:38:13
14:18:19.644 [uBO] loadFilterLists() Loading filters from urlhaus-1 at 254 ms console.js:38:13
14:18:19.685 [uBO] loadFilterLists() Loading filters from ublock-unbreak at 295 ms console.js:38:13
14:18:19.986 [uBO] loadFilterLists() Loading filters from ublock-filters at 596 ms console.js:38:13
14:18:20.205 [uBO] loadFilterLists() Loading filters from easyprivacy at 815 ms console.js:38:13
14:18:20.456 [uBO] loadFilterLists() Loading filters from easylist at 1066 ms console.js:38:13
14:18:20.552 [uBO] loadFilterLists() All filters in memory at 1163 ms console.js:38:13
14:18:20.629 [uBO] loadFilterLists() All filters ready at 1239 ms console.js:38:13
14:18:20.630 [uBO] Filter lists ready 1388 ms after launch console.js:38:13
14:18:20.631 [uBO] All ready 1390 ms after launch console.js:38:13
14:18:35.632 [uBO] Updater: cycle start console.js:38:13
14:18:35.633 [uBO] Updater: prefer CDNs console.js:38:13
14:18:35.878 [uBO] Full updater: successfully updated plowe-0 console.js:38:13
14:18:38.248 [uBO] Full updater: successfully updated urlhaus-1 console.js:38:13
Note that further restarts always result in the same degraded performance, updater running, etc., even after waiting for everything to complete
Expected behavior
Similar startup behavior regardless of filter settings in managed storage (only cached compiled user filters should be cleared)
Actual behavior
Slower startup, selfie not used, updater always runs, etc. when filters are specified in managed storage
uBO version
1.56.0
Browser name and version
Firefox 124.0
Operating System and version
Linux 6.6.5-arch1-1
The text was updated successfully, but these errors were encountered:
In 1.56.1+, the advanced setting cacheStorageAPI is to be used strictly for development purpose, it's not meant to be used in production. I should probably make that setting present only in the dev build.
Regarding the fix, I think the best way is that when toOverwrite.filters is present, the content should be compared with the current content of user filters, and if no difference is found, avoid invalidating cached selfie and compiled list.
gorhill
added a commit
to gorhill/uBlock
that referenced
this issue
Mar 23, 2024
Prerequisites
I tried to reproduce the issue when...
Description
If filters are specified via managed storage,
restoreAdminSettings()
callssaveUserFilters()
and attempts to remove compiled user filters from the asset cache. This happens prior tocacheStorage.select()
, meaning the wrong backend may be used to initialize the asset cache.The problem occurs when both
adminSettings.userFilters
ortoOverwrite.filters
is set in managed storagecacheStorage.select()
is calledindexedDB
)cacheStorageAPI
setting on 1.56.1rc0 and beyond (after cache storage redesign)I intended to open PRs but was unable due to access restrictions:
A specific URL where the issue occurs.
n/a
Steps to Reproduce
Note: these steps will overwrite all user filters
~/.mozilla/managed-storage/uBlock0\@raymondhill.net.json
with contents:Expected behavior
Similar startup behavior regardless of filter settings in managed storage (only cached compiled user filters should be cleared)
Actual behavior
Slower startup, selfie not used, updater always runs, etc. when filters are specified in managed storage
uBO version
1.56.0
Browser name and version
Firefox 124.0
Operating System and version
Linux 6.6.5-arch1-1
The text was updated successfully, but these errors were encountered: