Surrogates with no prefix do not run on script-blocked pages

[barbaz]

STR:
1) about:config, create these two prefs:
noscript.surrogate.test.replacement : alert('Cuckoo');
noscript.surrogate.test.sources : .flattr.com
2) make sure hackademix.net and (api.)flattr.com are script-forbidden, then visit https://hackademix.net/

Expected results: get an alert

Actual results: nothing happens. Only if I (Temp-)Allow hackademix.net do I get the alert.


The reason this is an issue is that I am trying to write a surrogate for a syntax highlighting system which can most easily be detected by its script, so it would be most efficient to have the surrogate just replace the script instead of running on all pages checking for the presence of the script.
If it is not desirable behavior for script surrogates (surrogates without prefix) to run on script-blocked pages in general, this is a RFE for a new surrogate prefix which behaves like the current "no prefix" except that surrogate will run replacing the script even if the page is script-blocked.

[Thrawn]

Well, if the top-level page is blocked, then scripts within the page aren't normally even considered. So I'm not sure it's feasible to replace them with a surrogate. NoScript effectively doesn't know that the specifically-blocked script(s) will exist once the page is script-allowed.

What you could do is define two sources (separated by spaces), one with no prefix and one with an exclamation point(!). That's about as close as I think you'll get.

[barbaz]

Well, if the top-level page is blocked, then scripts within the page aren't normally even considered. So I'm not sure it's feasible to replace them with a surrogate.

It's certainly feasible - surrogates run in a sandbox that isn't script-blocked. And because no site scripts are being allowed, it doesn't matter whether the surrogate runs exactly when the script "would" have. I would think NoScript can know the URLs of scripts it's blocking, so for script-blocked pages it would be enough to, say, run the surrogate on DOMContentLoaded when a matching script URL is blocked.

What you could do is define two sources (separated by spaces), one with no prefix and one with an exclamation point(!). That's about as close as I think you'll get.

The particular script I want to replace always seems to be hosted first-party, so just one ! surrogate would be enough in this particular case. But I simply dislike the idea of doing document.querySelector('script[src="..."]') when a more efficient (and more flexible) method of checking for specific script could be implemented in NoScript.

[Thrawn]

for script-blocked pages it would be enough to, say, run the surrogate on DOMContentLoaded when a matching script URL is blocked.

That's my point; I don't think that that happens when the top-level address is blocked. I don't think that Firefox ever passes the individual script URLs to NoScript in that case. Giorgio can correct me if I'm wrong. In any case, if NoScript does see the URLs, it probably has fail-early code that discovers we're in top-level-blocked mode and doesn't bother to consult the whitelist to determine whether this specific script is blocked.

So I'd be surprised if this is feasible without significant refactoring.

[barbaz]

In any case, if NoScript does see the URLs, it probably has fail-early code that discovers we're in top-level-blocked mode and doesn't bother to consult the whitelist to determine whether this specific script is blocked.

So I'd be surprised if this is feasible without significant refactoring.

NoScript *always* blocks scripts when top-level-blocked mode, so no need to consult the whitelist here.

IIRC when I've looked at NoScript's code it uses nsIContentPolicy to block external scripts, and Cu.blockScriptForGlobal() and/or nsIDocShell attributes to block inline scripts...