Why is subscriber.js running on a domain with no filter-subscription links?

[Rudxain]

More specifically, this:
https://github.com/gorhill/uBlock/blob/640eaf89d0e3fe7de9fa8a84524128e4133ce93b/src/js/scriptlets/subscriber.js#L80-L88

I was using MS-Edge (Chromium) memory profiler, selected "Allocation sampling", clicked on this <canvas>, stopped profiling, and noticed that callback was being triggered by my clicks.

Weirdly enough, this doesn't happen on the root endpoint (bare domain).

I was about to open a "Bug" issue, but realized it wasn't appropriate, as I checked all boxes, except for the last 3 (As "Dark Reader" and "DecentralEyes" were both enabled, but weren't doing anything. And I didn't reset anything to default)

Is this normal? How can I reduce the memory use of that scriptlet (or better, prevent the injection of the scriptlet)?

[gorhill]

Because of https://github.com/gorhill/uBlock/blob/1.56.0/platform/chromium/manifest.json#L53-L68.

A lot of 3rd-party filter lists are hosted on GitHub, and the maintainers of these filter lists like to have users be able to subscribe to their lists by just clicking on them.

The /js/scriptlets/subscriber.js content script is injected on these domains unconditionally because there is no way to know that a webpage at any of those domains contains subscription link without injecting the content script in the first place. The content script used to bail out immediately if it didn't find subscription links, but this didn't work for sites which update dynamically, such as https://filterlists.com/.

How can I reduce the memory use of that scriptlet

I doubt you would ever be able to measure actual memory used by that one scriptlet given the scriptlet is essentially just a single event listener for mouse click.

As a rule here, speculated performance issues are deemed invalid unless there is profiling data supporting that the performance issues are real and not speculated.

[Rudxain]

Thank you for the info! But what if we added a setting to disable subscribe-on-click? Or (maybe) even better, let no-popups control whether it's enabled or not (this is more granular), for security reasons