It is known that almost any browser has the possibility for cookie-settings to only allow cookies from the own (parent) website.

How to do that with scripts? While surfing on facebook I often get the error of "script ... (residing at ...akamai...) is too slow! stop it?"

How to set settings that when visiting facebook only scripts that reside at facebook.com are alloed and scripts residing at other sources are not executed? A log with all non-executed scripts in such a way would be nice ...

There's a native gecko pref for this setting and some other of the sort.
No log, sorry.

Try macro "permdefs" and for site exceptions the extension "ExExPermissions", they give you a menu for those "permission" prefs (both are here in extensions subforum).
And for people who want to toggle multiple of those prefs at once the Blockeria-macro might be handy too.

For testing you can simply add those prefs in about:config by right-click and with type "INT". Those prefs are:
"permissions.default.script" (or subdocument, stylesheet, object, media etc.)
1=all allowed, 2=all blocked, 3= no 3rd party

Even what Siria is saying is true, have in mind that blocking third party doesn't work as you imagine.

In a static site where all belongs to the same domain, third party is a subdomain.

Example:
www.facebook.com loading scripts from scripts.facebook.com and the rule set to block third party, won't allow scripts.facebook.com to load, although they are in the same domain.

About the Akamai error, have in mind that sites use CDN (Content Delivery Network) to save bandwidth an for performance across Internet (distance). Akamai is a CDN (the bigger, maybe).

If you block third party, and here a CDN is obviously a third party, you are blocking the main scripts of the site you are visiting.

In large sites like FaceBook, Twitter, Google, etc. Block subdomains, third party, is not really possible, unless you want undesired results.


I forgot to say that under Tools, Privacy, Permissions, you can control what sites are scripts allowed, but, also, with the large network of subdomains and/or CDNs, you'll have to allow a long list to ensure functionality and, even, is not guaranteed.



Edited 1 time(s). Last edit at 09/21/2015 09:05PM by JohnHell.

That's a bit what I fear: that main functionality is no longer working ...

But concerning FaceBook: I wonder that with K-Meleon usually a "big long page" is loaded (with lots of entires), visible at the very thin scrollbar-mover, while with some other browsers loading is just as you scroll down (about 5 entries at once, making the page increase by scrolling down).

Sure it's nice to have lots of entries at once on the one hand, but on the other that makes it slow (specially on slower PCs) and the entries are considered "already read" by FB even if you did not scroll down to the bottom ...

Facebook issues are mostly connected with modern web-techs and support for them in browsers.

For example, IE 8 (max for XP) doesn't support most of HTML5 and CSS3 techs. So the page using them will be shown without some things (important or less ones) - but it also makes less load on RAM and CPU, so your browser can run what it supports more quickly (Ex.: flash issue described by you).

That's the point: modern browsers try to render more data then old ones. But your RAM and CPU stay the same ;-)

Quote
Voltaire
But concerning FaceBook: I wonder that with K-Meleon usually a "big long page" is loaded (with lots of entires), visible at the very thin scrollbar-mover, while with some other browsers loading is just as you scroll down (about 5 entries at once, making the page increase by scrolling down).

Wow, didn't know that happens now. I just tested and a big bunch of entries are loaded at once .

Even on Firefox 31, as K-meleon 75.0 I'm using and spoofing the user agent.

OOOhhhh, I see what happens. The intelligent brains behind Facebook now load a full page when you are not logged-in xDDD.

Great!!!! Awesome feature

EDIT: by the way, you can use mobile.facebook.com to load the pages and without javascript. If you are visiting FaceBook unlogged, is more friendly this way.



Edited 2 time(s). Last edit at 09/25/2015 03:50PM by JohnHell.

I've been playing a little the last weeks with subdocument permissions (permissions.default.subdocument) and also with script permissions (permissions.default.script), and I found that I was partially wrong with my thoughts about subdomain and third parties from my past experience.

Using the example above, scripts.facebook.com won't be a third party to facebook.com, nor www.facebook.com.

To consider third party, Gecko look for the second level domain, facebook, in this case, so any third level domain, scripts, www, etc, won't be consider third party.

This doesn't change the fact that blocking third party isn't the solution, as I told above. As usually CDNs are used and CDNs, usually, are in another domain.

 



Edited 1 time(s). Last edit at 03/21/2016 12:22PM by adodupan.

Just to not let you search too far: these unresponsive scripts do not reside directly on a domain with "facebook" inside the name, but on https://static.xx.fbcdn.net/rsrc.php/v2/... and further .../yo/r/HuurJiMc8fm.js:109 or .../yr/r/rGuyBeDf_aN.js:5 and so on. So it's not the same domain, but visibly shows to be one of the Content Delivery Networks of Facebook. And the conclusion must be: stopping those scripts will probably make malfunction the main functionality of facebook itself that consists of: delivering the stuff people post ...

Btw: I have several screenshots here – among them the first mentioned script appears more than once ...



Edited 2 time(s). Last edit at 10/23/2015 08:46AM by Voltaire.