[kodablah]

That appears to be for blocking JS (and opt-in only via disabling JS on the site hosting the PDF). I am unfamiliar w/ the internals of PDFs (especially concerning JS invocation), but can you request an image from a third party site without scripting? Also, what if I want the PDF's features to work and I just want to filter web requests like I do every other page out there (e.g. to remove the referrer header)?

That web requests in PDF content types are not subject to the same approach as web requests in HTML content types is the problem. Disabling all JS is a blunt instrument akin to telling someone that being able to disable JS for other webpages is as good as more nuanced ad block extension.

[ldarby]

You seem to be in favour of some JS running but not other JS - how can software tell the difference? What do you mean by "nuanced ad block extension"? Do they just have a massive blacklist of bad actors to block?

[kodablah]

> You seem to be in favour of some JS running but not other JS

No, sorry if I was unclear. What I'm in favor of is my extensions being able to handle/filter web requests on PDFs the same as they do for webpages, irrespective of JS settings. JS is only under discussion here because of the linked commit and I'm saying that's not good enough.

[ldarby]

Ok, anyway I agree with that completely, which is why I disabled PDFs opening automatically and have to click to open (via a standlone reader, not browser plugin). It's basically the same situation as the bad old days of having Flash load automatically and it making whatever requests it wants...

[sangnoir]

However, you probably don't want your Cloud-to-Butt extension reading/modifying requests made by your password-manager extension - which is how I understood the NOFIX comment.