Quote
foliator
I only tried YesScript in version 43. Up until a few months ago I still had version 15.0.1; it ran OK

Having just today struggled with FF-addon stuff, have now took a look into its install.rdf, and it says Max Version for FF is 40. There's a chance it may work when editing it with a higher number.

Quote
siria

Quote
foliator
I only tried YesScript in version 43. Up until a few months ago I still had version 15.0.1; it ran OK

Having just today struggled with FF-addon stuff, have now took a look into its install.rdf, and it says Max Version for FF is 40. There's a chance it may work when editing it with a higher number.

"Struggle" is definitely the right term for working with Firefox addons -- and the recent versions of FF itself. I've about had my fill of that. Yesterday I removed FF from my system, as it was just a waste of space. The app, along with my profile, is safely backed up in a Zip archive, but I will only reinstall it if I start running into sites that KM can't handle; haven't seen one yet!

Considering all my experimentation with different browsers, maybe I'm just what's known as "a glutton for punishment" (I think the German expression is "eine masochistische Ader haben"). I even tried that new kid on the block, the Vivaldi browser. I uninstalled it after a single session.

---
Gerry

Using FF ESR 17. It had stopped working on too many sites. I was using QtWeb for those sites, but when I had to do income taxes, even QTWeb wouldn't work. Then I found KM. Now I am thinking all day about macros and livehttpheaders.

Edit: Try Pale Moon if KM doesn't work. I think their "Gecko" is a little more up-to-date, but I like the native feel and old-style hackability of KM.



Edited 1 time(s). Last edit at 04/17/2016 10:05PM by anontemp123.

on the Mozilla Addons site you almost always would be able to find the addon version, that works with your Gecko version - every addon has an archive of old versions down on the page.

No need to 'struggle' with addons, manifests, rdfs and so on. Just look for corresponding build of addon.

What am I missing here? URL: http://examples.oreilly.com/9781565922341/1.1.html

k-meleon blocks scripts loaded from separate js-files under domain listed.

And that site has javascript inline placed into html-code of example pages.

As rodocop said, the default Gecko browsers permissions are for external resources. If the page has a script in its code, that can't be blocked unless disabling JavaScript.



Said that, here you have the YesScript extension for K-meleon:
http://kmeleonbrowser.org/forum/read.php?9,138259

I will try out the extension and report back.

I tried to get used to the method of blocking Javascript by default and allowing sites one by one, however that feature won't work for my usage if I can't allow Javascript embeded in the page I'm currently browsing. As an aside, I wonder if NoScript allows this sort of thing.

Quote
anontemp123
I tried to get used to the method of blocking Javascript by default and allowing sites one by one, however that feature won't work for my usage if I can't allow Javascript embeded in the page I'm currently browsing.

Yeah especially for javascript this separation between internal and external sources, instead of current page URL, is just not practical, for me neither. One of the reasons I love the privbar so much! (the other reasons are the other priv-buttons ;-)) It can block or allow the whole page incl. all sources at once, and with just 1 click. The downside is that I tend to forget to toggle back and then after awhile "oops.."

Quote
JohnHell
Said that, here you have the YesScript extension for K-meleon:
http://kmeleonbrowser.org/forum/read.php?9,138259

Whoa - definitely way, way above my head! And LOTS of work. Again, just very glad you volunteer ;-)

Thinking about, isn't it already incredible that for such a simple (in theory) task like blocking JS by domain so much addon-code is necessary?! And now the additional macro requires such a load of code too!
Also am surprised, if reading the macro right, that the addon stores all the sites just in a single pref.
And all subdomains must get own entries??

Frankly so far haven't tried it yet (too little time, and it's slightly scary), just peeked into the code. But still am so bold to already have a suggestion :cool:
The title-prefix should be customizable by users. Also as short as possible, otherwise it covers too much of the real titles in the tabs.
(unfortunately something we can't help is that modified titles will also get stored in favorites etc.)
Ah yes, and the readme doesn't mention anything about renamed titles yet...

Line 43:
$_yesscript_titleinfo = "â›”YESCRIPTEDâ›” -- ";
There are two characters before and after YESCRIPTED, which show on my system either as rectangle or as UTF16-4number-icons. Wonder if it really works to check if titles starts with "YESCRIPTED" without that character before.

My most minimalistic suggestion would be to use instead
$_yesscript_prefix = "!";
And use that prefix-var also consistently in all comparison-lines, so that it's easier customizable, just 1 line in the beginning. Optimum would be by menu (yet more work, ouf - not mine.. run&duck.. ;-)



Edited 3 time(s). Last edit at 04/18/2016 07:31PM by siria.

I don't think it will block externally loaded JS if those JS are loaded programatically, either. Only those that are loaded through HTML tags.

Quote
anontemp123
I don't think it will block externally loaded JS if those JS are loaded programatically, either. Only those that are loaded through HTML tags.

What are you talking about there? NoScript?, YesScript?, Block JavaScript?

I'm lost.

Quote
siria
Whoa - definitely way, way above my head! And LOTS of work. Again, just very glad you volunteer ;-)

Thinking about, isn't it already incredible that for such a simple (in theory) task like blocking JS by domain so much addon-code is necessary?! And now the additional macro requires such a load of code too!

Yeah, well, there were 2 paths there, or just create a simple menu entry to the blacklist manager, or mimic the original add-on.

And may look crazy (has been, really, believe me (damn spaces and titles)) but actually, the add-on does "only" 2 things:
- block javascript in a whole to block page javascript.
- block any external JavaScript

The difference with others is just it does only for a particular domain before load it, so the rest of your browser session can be JavaScript enabled.

Quote
siria
Also am surprised, if reading the macro right, that the addon stores all the sites just in a single pref.
And all subdomains must get own entries??

That is the reason it looked feasible, the add-on is based on one pref storing domains.

But, no, it doesn't use it to store subdomains. Or yes, depending on how you understand it. It is explained in its readme (README.md) by the author.

It is not the same blacklist www.google.com and accounts.google.com.

Quote
siria
Frankly so far haven't tried it yet (too little time, and it's slightly scary), just peeked into the code. But still am so bold to already have a suggestion :cool:
The title-prefix should be customizable by users. Also as short as possible, otherwise it covers too much of the real titles in the tabs.

But the title is already in the Title Bar.

Sorry, I admit I haven't tested deeply in tabs. Aren't tabs showing a tooltip with the title on mouse over. I'll see now after I post this.

Don't kill me making it customizable It won't be difficult using a pref for that, but that is a few more code for something...

Well, if it is very annoying, I hear you. I could change if necessary.

Quote
siria
(unfortunately something we can't help is that modified titles will also get stored in favorites etc.)
Ah yes, and the readme doesn't mention anything about renamed titles yet...

Yeah, but for that it is as easy as disable temporarily the blacklisting and add to bookmark. Then, blacklist again.

Quote
siria
Line 43:
$_yesscript_titleinfo = "â›”YESCRIPTEDâ›” -- ";
There are two characters before and after YESCRIPTED, which show on my system either as rectangle or as UTF16-4number-icons. Wonder if it really works to check if titles starts with "YESCRIPTED" without that character before.

Ok, this is how it looks (screenshot taken from the forum with Symbola font installed on my system (but not set for title bar)):



It won't show correctly if you don't have an UTF-8 font set in your windows system appearance/theme for title bar.

I know, maybe I went so far with that, but I made thinking in modern Windows versions, that probably support it, or will support it by default. I have no idea. Maybe so advanced for its times LOL.

Quote
siria
My most minimalistic suggestion would be to use instead
$_yesscript_prefix = "!";
And use that prefix-var also consistently in all comparison-lines, so that it's easier customizable, just 1 line in the beginning. Optimum would be by menu (yet more work, ouf - not mine.. run&duck.. ;-)

What I said above.

If there are a good number of complaints. I could make customizable.




By the way @anontemp123 what are your thoughts? You haven't reported anything back here or in its thread.



Edited 2 time(s). Last edit at 04/18/2016 09:28PM by JohnHell.

Quote
anontemp123
I don't think it will block externally loaded JS if those JS are loaded programatically, either. Only those that are loaded through HTML tags.

I meant with KM's built-in Script Permissions, not yesscript/noscript. For example:

If JavaScript is globally enabled, and you then block JavaScript for a site in the Script Permissions, that won't affect inline JS code. And if the inline JS code then executes document.createElement('script') and loads an external JavaScript file, that external load won't be blocked, either. This makes the Script Permissions not useful for the sites I personally visit, except for two sites where I want exactly this behavior.

(Note the inverse is also true. Case for Javascript globally disabled. If you allow Javascript for a site, then inline JS code won't run, including any external JS loaded by that inline JS code.)

Edit: As for YesScript, I have no issue editing the macro if I want something other than YESCRIPTED.



Edited 1 time(s). Last edit at 04/18/2016 10:40PM by anontemp123.

Quote
anontemp123

Quote
anontemp123
I don't think it will block externally loaded JS if those JS are loaded programatically, either. Only those that are loaded through HTML tags.

I meant with KM's built-in Script Permissions, not yesscript/noscript. For example:

If JavaScript is globally enabled, and you then block JavaScript for a site in the Script Permissions, that won't affect inline JS code. And if the inline JS code then executes document.createElement('script') and loads an external JavaScript file, that external load won't be blocked, either. This makes the Script Permissions not useful for the sites I personally visit, except for two sites where I want exactly this behavior.

(Note the inverse is also true. Case for Javascript globally disabled. If you allow Javascript for a site, then inline JS code won't run, including any external JS loaded by that inline JS code.)

I don't totally ensure that, but I bet it will be blocked.

Have in mind that the permissions features doesn't care of how it is loaded but where it is loaded from.

I don't have any example page to test with now. And I've seen it a lot of times...

Quote
anontemp123
Edit: As for YesScript, I have no issue editing the macro if I want something other than YESCRIPTED.

In the end I've been working on it the last our. I'll publish later.

Oh, Siria, don't make suggestion, you know how addictive can be programming

Ok, I tested the above with my local server and now I can ensure that .js files called from dynamically created script elements are blocked through default Gecko script permissions.

In other words, I was right that permissions only care about where the file is loaded from, not how.

(Extension updated)



Edited 1 time(s). Last edit at 04/19/2016 12:06AM by JohnHell.

Quote
JohnHell
Ok, I tested the above with my local server and now I can ensure that .js files called from dynamically created script elements are blocked through default Gecko script permissions.

In other words, I was right that permissions only care about where the file is loaded from, not how.

Can you test the opposite? I mean allow Javascript, then set the Script Permissions to block for the domain you are loading from.

Maybe if you can post your sample JS, I can see if we are talking about the same thing.

Quote
JohnHell
In the end I've been working on it the last our. I'll publish later.
Oh, Siria, don't make suggestion, you know how addictive can be programming

LOL! Truly sorry :cool:

Thanks for the explanations. And for the screenshot - really cool sign!
But this just showed again the need for customization for some users.

Meanwhile have remembered there was also this obsolete permission system based on the "CAPS" policies (capabilities...), which also had a black-white list for scripts. That was actually based on page URL too, not "source". It would have been great, but blocked injectJS too! Therefore kinda useless again, at least for me. Just thinking again, what a kinda complicated task that must be, blocking JS by domain/page. Tss.

Quote
anontemp123

Quote
JohnHell
Ok, I tested the above with my local server and now I can ensure that .js files called from dynamically created script elements are blocked through default Gecko script permissions.

In other words, I was right that permissions only care about where the file is loaded from, not how.

Can you test the opposite? I mean allow Javascript, then set the Script Permissions to block for the domain you are loading from.

That way has been done.

If you have javascript disabled, directly no way to load scripts. Less dynamically.

Quote
anontemp123
Maybe if you can post your sample JS, I can see if we are talking about the same thing.

<script>
var ss = document.createElement('script');
ss.setAttribute('type','text/javascript');
ss.setAttribute('src','http://the external domain/aaa.js');
document.getElementsByTagName('head')[0].appendChild(ss);

</script>

I can't post a live example. I want to keep the domain names of the servers out of this forum.

Ah... you're gonna kill me, but remembered only now: $TITLE is overwritable!!
That allows for something as simple as $TITLE=$_prefix.$TITLE
Or when checking: if (index($TITLE,$_prefix)==0) {....
(would check for beginning (0) not somewhere in the middle (-1), but now dawns on me why you left " -- " hardcoded)

$hostname gives the domain (with or without prot, can't remember)
(oops was wrong syntax. Have cheated and looked into ancient javascriptsitelistpolicies.kmm, it got the prot+domain that way:
$_JSS_URL = substr($URL,0,index($URL,"://")+3+length(hostname($URL)));

(CORRECTION Later: $TITLE is NOT usable if Tabs are enabled. It actually only changes the WINDOW title, not the tab titles)



Edited 2 time(s). Last edit at 12/03/2017 12:00PM by siria.

Quote
JohnHell
I can't post a live example. I want to keep the domain names of the servers out of this forum.

You are definitely correct. Not sure what I'm doing wrong with "real" sites. But it works just fine with the following example. (I use pastie.org for sharing JS code.)

<HTML>
<HEAD></HEAD>
<BODY>
<SCRIPT LANGUAGE="JavaScript">
function foo () {document.getElementById("dummyDiv").innerHTML = "FOO";}
</SCRIPT>
<DIV id="dummyDiv"></DIV>
<SCRIPT LANGUAGE="JavaScript">
var ss = document.createElement('script');
ss.type = 'text/javascript';
ss.async = true;
ss.src = 'https://www.pastie.org/pastes/10803110/download';;
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ss, s);
</SCRIPT>
</BODY>
</HTML>

Edited 1 time(s). Last edit at 04/19/2016 04:20AM by anontemp123.

@anontemp123, just check twice the domain name added is the correct. Use httpfox/httpmonitor extension or livehttpheaders or whatever if you need to know exactly where is the js retrieved from.

Quote
siria
Ah... you're gonna kill me, but remembered only now: $TITLE is overwritable!!
That allows for something as simple as $TITLE=$_prefix.$TITLE
Or when checking: if (index($TITLE,$_prefix)==0) {....
(would check for beginning (0) not somewhere in the middle (-1), but now dawns on me why you left " -- " hardcoded)

Nahhhh, lets $TITLE being $TITLE. If not, I see myself mixing things.

But the check, when you are right, you are right. Having one indicator hardcoded, even would be better 0, the errors would be very rare. But lets check to 0, now with custom indicators, because leaving these things on the air makes things like 0-day flaws come later to slap in your face (lets say Flash ).

" -- " is just a separator. May like or dislike, but I find as a visually helper. It is hardcoded for the same reason: custom indicators.

Quote
siria
$hostname gives the domain (with or without prot, can't remember)
(oops was wrong syntax. Have cheated and looked into ancient javascriptsitelistpolicies.kmm, it got the prot+domain that way:
$_JSS_URL = substr($URL,0,index($URL,"://")+3+length(hostname($URL)));

More than 10 years ago I started using index and substr for my url cleaners (not ever matching hostname) and I got stick like glue to the method.

I wouldn't lie if I say, even if I read before, that I didn't know existed a hostname function.

Both methods are valid for the purpose. I'll left as original. Not much bytes wasted.

YesScript 2.1_1.12 installed as told in Readme.txt. Blacklist works (YesScript toolbar icon right click-->blacklist manager).

but i need WHITELIST and i can't get to it: Tools-->Privacy-->Permissions -->YesScript-->Blacklist/Whitelist--> it just won't open...

the reason i need a white-list: i browse with JS "OFF", but occasionally have to go to one of my favorite bookmarks that require JS and just forget to toggle JS "ON" with the macro by seria



Edited 7 time(s). Last edit at 08/25/2019 05:00PM by cpm1a_new.

Quote
cpm1a_new
YesScript 2.1_1.12 installed as told in Readme.txt. Blacklist works (YesScript toolbar icon right click-->blacklist manager).

but i need WHITELIST and i can't get to it: Tools-->Privacy-->Permissions -->YesScript-->Blacklist/Whitelist--> it just won't open...

the reason i need a white-list: i browse with JS "OFF", but occasionally have to go to one of my favorite bookmarks that require JS and just forget to toggle JS "ON" with the macro by seria

Read the reply in the other thread:
http://kmeleonbrowser.org/forum/read.php?9,138259,150574,page=1#msg-150574

But, again, the permissions don't work that way.

The whitelist and blocklist works as an exception to the always enabled JavaScript.

If you have JavasScript blocked globally, YesScript lists won't work, or, in other words, won't enable JavaScript for a specific site.


Maybe this description works better for you:
https://legacycollector.org/firefox-addons/4922/index.html



Edited 1 time(s). Last edit at 08/25/2019 05:16PM by JohnHell.

Quote
cpm1a_new
the reason i need a white-list: i browse with JS "OFF", but occasionally have to go to one of my favorite bookmarks that require JS and just forget to toggle JS "ON"

Old giant prob in mozilla browsers. Can't help it
That's what the Privacy Toolbar is there for, to quickly toggle the global setting on/off, and have the current setting clearly visible.
Luckily I need JS only rarely, and if necessary, just toggle and reload the page.

How I help myself additionally: there exist several javascript-levels, and if possible I toggle only as much as necessary: the global main switch, to get at least inline js-scripts. If necessary, plus the permission for external js-files, from same domain. If necessary, also for foreign domains. And at most, a separate permission for XHR (something like ajax)
And some little JS-tweaks are also possible automatically by macros, without toggling JS on. Mainly redirects or image replacements etc which can run automatically at the OnLoad event. And also have lots of little style tweaks, to unhide hidden stuff. And of course, stylekiller macro which reveals almost everything. All together frankly one big chaos...
But writing all those little tweaks is quite complicated and time consuming, poking around in the page source code, and often requires all my (limited) skills, sigh. Definitely no solution for normal users.

That's why so many people insist on NoScript and adblockers or umatrix for browsing. Such addons need the JS main switch enabled all the time too, for themselves. And then they try to blacklist just about everything else. And this way it's then possible for them to whitelist again a few selected sites. Personally just have no experience with those, and prefer to keep JS really switched off globally. Despite the disadvantages.
Of course, what way works better mainly depends on which sites one needs to visit regularly!



Edited 1 time(s). Last edit at 08/25/2019 06:24PM by siria.

Perhaps there's a completely new approach to whitelist sites for javascript... Although probably highly risky... or perhaps only works in older KM versions? Not sure.
The key is macros and injectJS. Macros are whitelisted automatically and can inject javascripts themselves. That was always clear, but only recently I made two slightly worrying discoveries:
When macros inject scripts which open several alert or confirm boxes in a row, which the user must click, which can take seconds or minutes or even hours, the global JS permission seems to remain open globally all this time - also for websites to run their own scripts. Guess that means the macros are not really whitelisted, just the injectJS-command auto-toggles the global setting on+off. Just for a split second usually, no much harm possible, except if there are popups to click which take time.
But the real shocker was: when rewriting a page with injectJS and "document.write", just for the purpose of changing the DocType but otherwise the page content left original, the original scripts in the page seem to get executed automatically! Didn't see much of it on the current page, but the error console listed JS errors which could only be caused by a page script. Thinking about, this may seem even logical, but never realized it before so clearly.
The point is: perhaps when a whitelisted page was loaded ($OnLoad event, the only possibility to jump in), a macro may take the whole page and inject its content again?
But so far that's just a theoretical thought, and feels rather unsafe to me. But perhaps it could just copy single selected scripts from chosen pages and activate those again?
And am aware that "document.write" doesn't work anymore in KM76, but wonder if replacing inner/outerHMTL would have the same effect? But just a theory, would need much testing, and if working please only used by cautious users :-/

But that is the normal behaviour.

I don't know if it was adodupan or another user, years ago, or maybe it was Dorian, I can't remember, JavaScript is always on for inner workings in the browser, as per XUL interface, for example (that I don't know if macros rely on this, anyway).

So, macros and injectJS don't enable JavaScript temporarily. Without knowing the mechanism, lets say that injectJS works sandboxed but interacting with the page without touching the global javascript option.

But that is not the point, the behaviour you describe is normal. If you run your injectJS when javascript is enabled, when a dialog window is opened the browser gets "stuck" for certain actions, but if at that moment JS is enabled, JS would be enabled until you close the dialog. There is the chance that you could still browse in another tab/window with JavaScript enabled, but that's because you can't control certain actions as disable JS when is stuck with that JS dialog open.

Sadly it had happened to me a lot And, to be fair, I wouldn't recommend to browse that way, because the K-meleon interface gets frozen, you can't interact and you don't know if something is "toggleable" because you lose the control of K-meleon inteface and actions.

It isn't just risky, it is not recommendable. And lets not invent a new way to whitelist/blacklist that is against the engine because you can find unexpected results.



Edited 1 time(s). Last edit at 08/26/2019 01:22AM by JohnHell.

Seems like we almost fully agree, for a change ;-) This is a rather hot method. But the one use case that seems rather interesting to me is to somehow import+start selected native page scripts on chosen pages. And probably best started manually, while no other tabs are still loading. But not sure if even still possible in KM76. And also important to know for less macro savvy readers, the use of that method is quite limited too: It would work only once for a short moment, to transform the page content or redirect it etc., but afterwards the macros plugin immediately shuts down general JS access again. That makes the pages rather static again. If afterwards for example clicking a page button containing a javascript action, it would do nothing anymore.



Edited 1 time(s). Last edit at 08/26/2019 08:59AM by siria.

Or I didn't understand you in first place, or you haven't understood me.

I wasn't agreeing to anything.

I was saying that that is a normal behaviour, but normal, as a bug that shouldn't be abused, as the bug has the effect of freeze the K-meleon interface, and, as you noted, web functionality.

If I'd demand any change, and I don't remember if I have said openly in the forum earlier, there should be an event to take actions before on load. An event as $BeforeOnLoad, for example. To mimic the XPI/Firefox add-ons and their observers (as refcontrol, for example), to let use native macros calls before the page loads.

I read the other day some user saying can be done, but whoa, that is beyond me. Rather complicated.

1) to add YesScript to KM all i need is YesScript 2.1_1.12.zip (i.e. no native FF extension installation needed). did i get it right?

i browse most of the time with JS disabled
2) is there any reason for me using YesScript 2.1_1.12 instead of built-in global JS toggle?
i see just one point: if i enable JS and then FORGET to disable when no longer need it, YesScript will keep blocking JS as set in the Blacklist manager

3) are YS and built-in toggle block equally efficient?

4) with YesScript i don't see any noticeable slowdown, am i right?



Edited 2 time(s). Last edit at 08/27/2019 12:31PM by cpm1a_new.

Quote
cpm1a_new
i see just one point: if i enable JS and then FORGET to disable when no longer need it

That's the only point where I can help a little bit. If you like I can post my little javascriptwarner macro for the extra paranoid (like myself / it just needs a bit more polishing before posting)
That macro just shows a warning after every page load, as reminder that javascript is enabled:



It's only checking this pref: "javascript.enabled", nothing else.
When disabling the warning (stop asking), an input will popup to ask when the warning shall be activated again:
when switching tabs / switching windows / at next session / or never



Edited 2 time(s). Last edit at 08/27/2019 01:19PM by siria.

Please, post questions for a extension, in its extension thread as is told in its Readme.txt That helps to keep the health of the forum
http://kmeleonbrowser.org/forum/read.php?9,138259,150574

But, as it is too late for that, lets reply here.

Quote
cpm1a_new
1) to add YesScript to KM all i need is YesScript 2.1_1.12.zip (i.e. no native FF extension installation needed). did i get it right?


i browse most of the time with JS disabled

The extension is an adaption of an XPI old style Firefox extension to work with K-meleon. You only need that file AND FOLLOW THE INSTRUCCIONS IN README.TXT

Quote
cpm1a_new
2) is there any reason for me using YesScript 2.1_1.12 instead of built-in global JS toggle?

Lets start from the begining. Firefox didn't have the permission options K-meleon had (Tools Menu > Privacy > Permissions > Javascript).

What YesScript does is the same as that feature in K-meleon for Firefox, but if I was correct when I wrote it here, blocks all javascript running from a given url/domain/page. I just adapted it per request by an user.

Quote
cpm1a_new
i see just one point: if i enable JS and then FORGET to disable when no longer need it, YesScript will keep blocking JS as set in the Blacklist manager

Read the reply above

BUT YOU CAN'T BLOCK ALL THE NET IF YOU FORGET IT, only what is blacklisted.

Quote
cpm1a_new
3) are YS and built-in toggle block equally efficient?

They are the same. Firefox didn't have any kind of Toggle/Permissions feature as K-meleon had.

Quote
cpm1a_new
4) with YesScript i don't see any noticeable slowdown, am i right?

You shouldn't. It just checks the URL and block JavaScript on the fly. But the add-ons language in Firefox is beyond my knowledge. I only know that implants observers to know when to do anything.

And I said BLOCK. Firefox doesn't have a toggle for JavaScript and is always on. This extensions, and its adaptation to K-meleon is just the effort of Firefox users to block JavaScript on demand for certain sites.

That is the reason that Firefox and other browsers have add-ons like NoScript.