General :  K-Meleon Web Browser Forum
General discussion about K-Meleon 
Pages: 12Next
Current Page: 1 of 2
javascript policies by website
Posted by: snuz2
Date: June 21, 2011 06:14AM

Does anyone know how hard would it be to add a whitelist/blacklist control for javascript like the ones for flashblock or even better like the one for cookies, popups and images? where would i edit the code to add this? I know there are some extensions that sort of do this but they are way to big and complicated for what i want to do. looks like they require auto-it which i am not interested in. Thanks.

Options: ReplyQuote
Re: javascript policies by website
Posted by: siria
Date: June 21, 2011 07:18AM

Have played with the same idea awhile back, when I found that gecko has a native system to handle exceptions lists by the "capabilities.policies" prefs ("CAPS"). Those prefs are intentionally hidden in about:config, only visible in prefs.js directly.
So I made a little macro with menu, all in macrolanguage, that adds pref-toggling and white-black-list stuff to the javascript-button. No GUI, just menu that pops up a prompt line for input/editing. Sort of a very primitive policies manager, as it was perhaps in version 0.1alpha ;-)

That macro was experimental, still sitting somewhere on my harddrive, but the one crucial problem remained: There are just 2 "general" javascript blocks, one by capabilities (which handles black-white-lists, but unfortunately blocks all native KM commands which are based on JS, like guess zoom options), and the other general JS setting from privacy menu, which ignores the whitelist!

So if you're willing to have JS *active* by default, and only use a little blacklist, you could start out playing further with that macro. But if JS should be blocked by default, it's useless sad smiley If several pages are loading at the same time, ALL would be allowed JS, or the other way around, lots of other useful macro commands will stop working.

A little bug: Just yesterday discovered, while playing with another macro, that pref-editing (BW-list) via prompt line only accepts lists of up to 255 characters, didn't know that yet! The prefs can hold much longer values, just not input via prompt line. So would have to add the workaround of copy/pasting longer lists via clipboard and notepad, like in my other macro.
Ah yes, and have quite some notes in that macro for more probs! E.g. the CAPS BW-list doesn't judge by the origin of a script, no, third-party scripts can have their source anywhere and are still allowed, if the current page url is whitelisted! Or only complete domains are toggled, no sub-domains possible as exception. And so it went on... Have it given up.

--> Long live the privbar! grinning smiley
Like it best anyway, JS-state always clearly visible, no gray cells needed for remembering exception sites smiling smiley

Then again... there was also some way to handle BW-stuff in HOSTS-file, perhaps that's better?? But the KM hosts file doesn't work in 1.6 anymore (guess due to gecko changes) And even the windows hosts file doesn't seem to fully work in it anymore. Have a KM menu line to simply open that one in notepad, the ultra-basic-mini solution ;-)

Oh well, can't swear on all that stuff above any more, been too long, have too much forgotten of it meanwhile sad smiley



Edited 5 time(s). Last edit at 06/21/2011 07:40AM by siria.

Options: ReplyQuote
Re: javascript policies by website
Posted by: snuz2
Date: June 21, 2011 08:53AM

blacklist only would be okay, i just have some sites with annoying JS that doesn't effect their function beyond long load times.

you're right, hostperm isn't being used anymore, looks like it's in permissions.sqlite. but it looked like a good place to block a few sites! maybe i can edit an old hostperm file and then use the compat macro to read it in...or edit the sqlite in another app...



Edited 1 time(s). Last edit at 06/21/2011 09:22AM by snuz2.

Options: ReplyQuote
Re: javascript policies by website
Posted by: siria
Date: June 21, 2011 10:31AM

Editing sqlite sounds very useful. Guess have read about it some time ago, about some tool, was perhaps even a kmext macro?? But too busy with other stuff to research about that now. Experts like disrupted sure can tell a lot about it.

As for just blacklisting JS on a few domains, my experimental CAPS macro would probably well suffice, can upload it when I'm home again if you'd like to try it.

Options: ReplyQuote
Re: javascript policies by website [Warning: Experimental]
Posted by: siria
Date: June 21, 2011 07:47PM

Have now uploaded that experimental macro, if anyone wants to test it (javascriptSitelist.kmm)
First two pages are notes, just ignore that. For short lists (<256 signs) it should work, if I remember correctly... Have a workaround via clipboard for longer entries in another macro, but not added here yet. Guess for a bit testing it's long enough ;-)

Be aware that many commands like image zoom will stop working on pages that get javascript blocked by this capability.policy sad smiley

The menu appears in Tools > Privacy > Permissions

WARNING: EXPERIMENTAL!
(may have bugs, make a backup copy of your prefs.js in current profile first, download the macro into the PROFILE macros folder)


(http://... oops, bug found, have link deleted until fixed)
(download needs cookies and referrer allowed)

Tip: Add K-Meleons menu for exceptions (cookies, images, javascript etc.) also to the privacy toolbar's javascript button, on right-click. Click Edit>Configuration>Toolbars (or manually open toolbars.cfg in current skin folder). Replace
macros(pref_ToggleJavaScript)
with
macros(pref_ToggleJavaScript)|P&ermissions

Perhaps I should mention, in case anyone isn't aware of it yet: If you have added websites to this black/whitelist, they are written to native gecko CAPS prefs, and deleting/uninstalling the macro file (.kmm) does not mean that those BW-Lists would stop working! The macro just created a menu to edit those gecko prefs easier.
Without it, you can also edit the BW-lists manually, close the browser and then open "prefs.js" in current profile folder, with a text editor like notepad. Delete those lines or edit the page addresses:
user_pref("capability.policy.jsblacklist.sites", "example.com www.example.com ");
user_pref("capability.policy.jswhitelist.sites", "example.com www.example.com ");



Edited 4 time(s). Last edit at 07/16/2011 09:00PM by siria.

Options: ReplyQuote
Re: javascript policies by website
Posted by: snuz2
Date: June 22, 2011 04:34AM

Got it. I am very busy too, so I may not post for a while...Thanks siria...

PS yeah it's long enough!



Edited 1 time(s). Last edit at 06/22/2011 04:34AM by snuz2.

Options: ReplyQuote
Re: javascript policies by website
Posted by: snuz2
Date: June 29, 2011 05:37AM

@siria
I condensed and cleaned it up. It works fine for just blocking a few troublesome sites. Should we upload to macros area? You want to take a look first?

Options: ReplyQuote
Re: javascript policies by website [Warning: Experimental]
Posted by: siria
Date: July 01, 2011 08:55PM

Hmm, if you think it's okay for a mini-blacklister...

Would like to add that stupid workaround for longer strings first, and condense the macro myself, but facing reality, that could take some days until I get around or some years, so... Perhaps post your own mini-version just here for now? ;-)



Edited 1 time(s). Last edit at 07/16/2011 08:59PM by siria.

Options: ReplyQuote
Re: javascript policies by website
Posted by: snuz2
Date: July 02, 2011 02:37AM

well the strings IS a problem, but i don't think most people will ever really need to edit the list, so maybe we should just take that out and leave the options to view the list of sites or clear it completely. The toggling works well now and you can check the menu to see if a site is blocked as well. Try it out smiling smiley It's not that "mini" as it stands.

i swear there was an upload button on this forum last night but i can't find it now O_o...

    CODE DELETED AT AUTHOR'S REQUEST



Edited 3 time(s). Last edit at 07/06/2011 05:08AM by snuz2.

Options: ReplyQuote
Re: javascript policies by website [Warning: Experimental]
Posted by: siria
Date: July 02, 2011 09:22AM

Oops - Darn, first major bug found, and it's my fault!! :-(
Had not intended it at the time for publishing, was only half-way finished yet. And now last week didn't spend much time on checking it again. But now when looking at your mini-version, it downright jumped into my eyes!

BUG: The first line without # (after startup) deletes a possibly already existing list of various policy zone names! (could have been created by PolicyManager or other)
Yes, you just copied the bug that was already in my long version.

That's a bit dangerous really, although it can be fixed with Notepad:
opening prefs.js while the browser is closed and complete the zones list again manually.

But who knows what other bugs may be in it still?? Cannot spend too much time on it currently, and see no real future for it. Perhaps for a mini-version some day, might be, but have not enough time currently. The main (huge) prob is that it can interfer with other CAPS-zone-macros. Simple example: how are the zones names separated in the list?? Can be either blanks or commas acc. to Mozilla. So if one macro uses blanks and the other commas, it produces a mix, and I doubt that would work well :-/ And is there this separation character also at the end, or not? And how about the beginning? Yes it basically works - but only as long as no other such macro is used. The real challenge would be to avoid all imaginable side-bugs when interfering with them (especially policy manager),

Please snuz, mark the mini-version clearly as "Experimental" too, in the posting and inside the kmm as well.
I'd also prefer to make yours completely independant from my "sitelist", that means renaming all the "sitelist" and "JSS" to your own name, which is fine. Some you have replaced already, but not all. In the kmm you could write something along the lines of "by snuz2 (based on experimental macro by siria)" or such. Hope it's okay for you.

You can replace the first buggy line with:
$_zones=getpref(STRING, "capability.policy.policynames");
if (index($_zones,"jsblacklist")<0)
setpref(STRING, "capability.policy.policynames", $_zones."jsblacklist, ");

But there it starts again: What if there's already an existing zone named e.g. "myjsblacklist" or "jsblacklist5" etc.?? What if an existing list ends without separation character? Should I add a blank, just in case, or perhaps a blank+comma?? Would take quite some coding to first examine and check the current syntax before adding more zones. Sigh. Or perhaps merely check if there is ANY list existing yet?
if($_zones=="") ...
At any rate it takes quite some work yet.

Ah yes, here's a link to the Mozilla page, how their CAPS policies work exactly:
http://www.mozilla.org/projects/security/components/ConfigPolicy.html



Edited 2 time(s). Last edit at 07/16/2011 09:00PM by siria.

Options: ReplyQuote
Re: javascript policies by website
Posted by: snuz2
Date: July 06, 2011 05:04AM

as far as I can tell, only spaces work as seperators, it is okay to have multiple spaces, commas don't work at all. this agrees with mozilla documentation. so there is no real issue other than the one you identified, that a pref may be overwritten on startup.

but it sounds like you don't really want to post it, and i have no preference, so i am not going to post it. thanks for helping me out with it though.

Options: ReplyQuote
Re: javascript policies by website
Posted by: JamesD
Date: July 16, 2011 06:38PM

I have found a way to overcome the list edit problems. My whitelist from Policies Manager was 1648 characters long and would not work. I have a different method of edit for you to look at and experiment with. I have only done whitelist and not blacklist yet.

Edit:
The question is if this will work for languages needing utf8. This method uses index() and substr(). It works OK in ASCII for me.


Edit: code removed



Edited 3 time(s). Last edit at 07/22/2011 11:31AM by JamesD.

Options: ReplyQuote
Re: javascript policies by website
Posted by: snuz2
Date: July 18, 2011 08:27AM

wow. does the whitelisting even work? the problems siria reported with it seem to make it not worthwhile. it's like a workaround for a workaround....

Options: ReplyQuote
Re: javascript policies by website
Posted by: JamesD
Date: July 19, 2011 06:22PM

@ snuz2

I think the whitelist should work. It has the very same form in prefs as Policy Manager sets up. see below
From KM 1.6.0 beta2 (Policies Manager)
user_pref("capability.policy.Require%20JavaScript.javascript.enabled", "allAccess");
user_pref("capability.policy.Require%20JavaScript.sites", "https://....

From KM 1.7.0 a2 (JavascriptSitelist.kmm)
user_pref("capability.policy.jswhitelist.javascript.enabled", "allAccess");
user_pref("capability.policy.jswhitelist.sites", "https://...

I had expected to hear from siria about the 'edit' method that I am testing. I still have to include some validation code to handle any little odd things coming back from the edited ini file. How do you like my edit method?

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: siria
Date: July 19, 2011 07:18PM

Uhm, frankly I've given up on the whole macro for now. Perhaps I'll work at it some day again, one never knows, but not very soon. It was just experimental, for testing those Mozilla CAPS policies, and fell through. The inherent bugs (lots of KM commands and macros don't work on blacklisted sites) are IMO too restricting for daily use. As snuz said, to blacklist a few bothersome sites it's quite okay, especially if someone knows what he's doing.

Must admit am not overly happy to see the whole messy thing incl. all personal coding babblings posted so "out in the light" now, oh well.
Please do me a favor and fix at least my stupid old line that deletes a user's existing policies list, the line after "MINE, probably from testing". It was just meant for my own personal testing at the time, not for other people. That setpref line can be replaced with the 3 blue lines from my other post a bit higher above, then it shouldn't delete existing policy names anymore. Not sure about the commas, but that's minor if anything.

Regarding the workaround, uhm, that's nice to help, but haven't really tested - it's just sooo long and complicated with iniwrite etc., would take so much time to examine it closer, and I need that time much more urgently for my current macros (and not to mention RealLife work :-/)
I did read a bit through it though, and noticed it also needs notepad as a workaround, so frankly, am tempted to rather consider my workaround from OnEventCheck, to throw the long string into the clipboard, tell the user via alert to paste/modify/and copy back into clipboard, then close alert.

But am sure your iniwrite-workaround can come in handy some day for another macro!

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: JamesD
Date: July 19, 2011 08:55PM

@ siria

I am sorry about early posting. I did not understand that I should not do that. I will remove personal stuff and continue to work unless you want me to drop it completely. I will also have a look at fixing the code with the three blue lines. I pretty much have to do this even if it only for me. I have 60+ items in my whitelist and they just will not fit in an alert. This method ( the ini file ) also gets me past the problem of only 255 character returned from the prompt().

I must have some system in place because Policy Manager will not run in KM 1.7.

I am working on code to validate the reads from the ini file. Users don't always follow directions. Also I am looking at how to sort the list. It seems like the sort key must be the text between the rightmost dot and the dot next to the left.

I will not post code again until I can check with you in some way.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: siria
Date: July 19, 2011 10:56PM

Oh, didn't know there's a prob with KM1.7, and you have personal use for this. So I understand better now you spend so much time on it ;-)

Perhaps a thought, but the catch is, it requires manual editing of pref in about:config. Modifying prefs over there seems to accept longer strings, unlike a "normal" prompt. Or so I think, 99% sure ;-) The caps prefs could perhaps be copied by a macro into another pref, which is visible in about:config, then manually edited there, and then copied back into the original pref via macro again. Actually I had also played with such a workaround recently. A part of it:
_xxxPrefs_CAPA{
index($_pref,"capability.")==0 ? $_pref=sub("capa","CAPA",$_pref) : 0 ;
}
_xxxPrefs_capa{
index($_pref,"CAPAbility.")==0 ? $_pref=sub("CAPA","capa",$_pref) : 0 ;
}

And that sorting problem I recently had too grinning smiley That was a tough one, and in the end I didn't need it at all, oh well. It's a slightly alien workaround, but otherwise it works fine. For what it's worth, perhaps you can use some ideas from it, no idea. May need a bit adapting to your purposes. It can sort variables and prefs, but their name must be hard-coded inside, so I see no universal use at the moment.
http://www.datafilehost.com/download-38a7fec3.html

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: snuz2
Date: July 21, 2011 02:14AM

@james
I don't like it! it's what I was referring to "as a workaround to a workaround". I would generate a new html page and display it, make all the entries hyperlinks that open in a new window, that way it's easy to go and load the page and toggle it's permissions. Not sure you can do that without js enabled though!

Now that the toggling works, it's almost unnecessary to edit the list anyway. it would be nicer if there was a way to display an icon on the status bar that shows the js state for the page if it's on either list. bcuz some people such as me, don't use the privacy bar. anyway the privacy bar doesn't say why js is black or white listed and tells the user nothing about how it got that way...i also thought of injecting css to put a small image onto the page, clearly indicating that it's js state has been "tampered with" since the page could be blacklisted (how I use it), I assume that injecting js would not work, but css should.

lots of js doesn't seem to work properly in 1.7 yet anyway, like scroll to top and whole bunch of other stuff.



Edited 1 time(s). Last edit at 07/21/2011 02:15AM by snuz2.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: JamesD
Date: July 21, 2011 11:40AM

@ snuz2

I have not yet investigated the toggle aspect. Was too busy getting a method where I could see a long list. I have it now where I can see the list, edit the list, and choose to rewrite or not rewrite the list.

Easy enough to put a note on statusbar with 'whitelist', 'blacklist', or default. I could kick it off from OnLoad. Not sure what would happen with pages loading in background. The question is would the user want that much overhead for every page load. Let me think about this some more and maybe I will get a better idea.

I am not a JavaScript expert. I have written html for a page but that was using JS in wscript instead of injecting it. It would not work for long lists unless I were to read the pref.js file. That may cause problems with languages that require utf8. We may soon have urls in those languages.

Not sure about showing incremental progress here. I think I told siria that I would check with her before posting code again.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: JamesD
Date: July 21, 2011 11:54AM

Quote
siria
Oh, didn't know there's a prob with KM1.7, and you have personal use for this. So I understand better now you spend so much time on it ;-)

siria,

I don't use 1.7 now except to test. However, since Policy Manager will not run in 1.7, I have a concern whether it will run in the next KM. I need to have backup plan and JavascriptSitelist.kmm is the only available option that I have seen. It is really good work. I just could not fit my 62 item, 1652 character list into your original edit method.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: siria
Date: July 21, 2011 04:44PM

Hi James, I can't currently spend time on it, and not sure if it's worth, but you can always make your own version. Like a fork or something ;-) Perhaps call it JavascriptSitelistJD or whatever. I just do not wanna be responsible if people have trouble with bugs or such, since my last version is not finished in any way grinning smiley
For importing old strings, advanced users can copy them over via prefs.js in notepad. Perhaps some day I'll add my clipboard/notepad/clipboard workaround, not sure when and if.

Must say I'm still surprised there seems a need for it. I just figure that there will be some updated plugin for 1.7 when it becomes beta or stable, be it adblock or noscript or PolMan or whatever, and that will probably be a far more "professional" tool than my toy here ;-)

That statusbar text sounds interesting, and I'm fascinated by the CSS idea! That would really be it! grinning smiley
For testing how it could look I've added a dotted red border to my adblock.css:
html {border: 4px dotted red !important;}


Of course that would have to be injected "OnLoad" by a macro, after automatically checking whether or not a page is contained in the blacklist.

Anyway, just for testing looks have it added to adblock, which makes it visible on all sites, regardless their JS settings.
And must say it looks funny grinning smiley As expected, the catch is that it doesn't work right on all sites, depending on their own css structure. E.g. it's messy on that site:
http://www.w3schools.com/jsref/dom_obj_document.asp
Personally that would still be good enough for own use, but for publishing it in a macro it looks to silly grinning smiley

Or to add an image (e.g. some bold colorful line) at beginning of a page, am testing that css:
html::before { content: " " url(resource:///icons/blocked-JS.png) " " ;}
(of course the image name and folder are random)



Edited 4 time(s). Last edit at 07/21/2011 06:41PM by siria.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: JamesD
Date: July 21, 2011 05:22PM

Quote
siria
Hi James, I can't currently spend time on it, and not sure if it's worth, but you can always make your own version. Like a fork or something ;-) Perhaps call it JavascriptSitelistJD or whatever. I just wanna be responsible if people have trouble with bugs or such, since my last version is not finished in any way grinning smiley
For importing old strings, advanced users can copy them over via prefs.js in notepad. Perhaps some day I'll add my clipboard/notepad/clipboard workaround, not sure when and if.

I will fork the code. I will take responsibility for that which I publish. It will likely change in appearance also. Host file is not something I use much so it might not be in my work.

Persons importing by using notepad to copy parts of prefs.js should be aware that lines long enough to wrap may lose a blank space separating items. It seems to happen to me.

Thank you for the head start on this project. Your research is excellent.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: siria
Date: July 21, 2011 06:18PM

Good luck with it smiling smiley

And Oops, just seeing in the quote that I forgot "do not" (wanna be responsible), of course!! Stupid typos tongue sticking out smiley

Still playing a bit with CSS marking.
Exchanged "body" with "html", looks a bit better, there's no padding around it. But it's still sometimes shattered across page, and while borders aren't too bad, the CSS-image may appear multiple times too on a page, and that looks more confusing.

Looks like that css 'shattering' happens around iframes... On one hand quite interesting to see there's an embedded page in a page, on the other hand it overwrites a possibly already existing border around those boxes. Have searched around to find a way to affect only the 1st html element, but no chance with css. There seems a way in JS they say.



Edited 3 time(s). Last edit at 07/21/2011 08:21PM by siria.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: siria
Date: July 21, 2011 11:03PM

Couldn't stop playing with those borders, oh well ;-)

If anyone has use, this can be added somewhere in the macro, to get either red or green dotted borders after a page is loaded. Border only if it is in either the black- or whitelist, not listed sites get nothing.

#============ CSS: Dotted borders if page is in a zone ================

$_JSBlacklist_css="html {border: 4px dotted red !important;}";
$_JSWhitelist_css="html {border: 4px dotted green !important;}";
$OnLoad=$OnLoad."JSS_injectCSS;";

JSS_injectCSS{
$_JSS_URL = substr($URL,0,index($URL,"://")+3+length(hostname($URL)));
index($_JSWhitelist, $_JSS_URL) >-1 ? injectCSS($_JSWhitelist_css) : 0;
index($_JSBlacklist, $_JSS_URL) >-1 ? injectCSS($_JSBlacklist_css) : 0;
}


The borders are updated only after page loading has finished.
If anyone wants to change borders also automatically after TOGGLING, insert the css lines into the "ToggleURL"-macros (black+white):

JSWhitelist_ToggleURL{
$_JSS_URL = substr($URL,0,index($URL,"://")+3+length(hostname($URL)));
if (index($_JSWhitelist, $_JSS_URL) >-1) {
$_JSWhitelist = sub($_JSS_URL." ", "", $_JSWhitelist);
setpref(STRING, "capability.policy.jswhitelist.sites", $_JSWhitelist);
injectCSS("html {border-color: gold !important;}");
} else {
$_JSWhitelist = $_JSWhitelist.$_JSS_URL." ";
setpref(STRING, "capability.policy.jswhitelist.sites", $_JSWhitelist);
injectCSS($_JSWhitelist_css);
}
&JSS_syncButtons;
}

This will show immediately green or red borders right after toggling, without reload. If the toggle *removes* the page, the borders turn yellow, and will vanish after next page load...

-

Quote
JamesD
#========================= AT STARTUP

# MINE, probably from testing Policies-Manager: Trusted-Sites, test, wideopen
BUG: setpref(STRING, "capability.policy.policynames", "jswhitelist, jsblacklist, Trusted-Sites, test, wideopen, ");
#setpref(STRING, "capability.policy.policynames", "jsblacklist");

Please James, the red line deletes a users's existing list, replace it in your posting with the 3-blue-lines-fix, thanks...



Edited 2 time(s). Last edit at 07/21/2011 11:09PM by siria.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: JamesD
Date: July 22, 2011 12:42AM

@ siria

I think I have the fix put in so that my code will not overwrite an existing list. I think I am going with statusbar instead of CSS for display about which list the URL might appear.

I am testing my code in KM 1.7 and I think I have found a bug. It did not become noticeable until I began testing the reset code.

$_JS_Blacklist = getpref(STRING, "capability.policy.jsblacklist.sites" );
$_JS_Origlist = getpref(STRING, "capability.policy.jsblacklist.sites" );
alert(length($_JSBlacklist), "Length of $_JSBlacklist DEBUG", INFO);
alert(length($_JS_Origlist), "Length of $_JS_Origlist DEBUG", INFO);

The code above gives two different lengths. The second read is one less than the first. Can anybody confirm that it is not just me?

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: siria
Date: July 22, 2011 06:34AM

Quote
siria
You can replace the first buggy line with:
$_zones=getpref(STRING, "capability.policy.policynames");
if (index($_zones,"jsblacklist")<0)
setpref(STRING, "capability.policy.policynames", $_zones."jsblacklist, ");

Well, of course that was also meant for both, B+W-List:

$_zones=getpref(STRING, "capability.policy.policynames");
if (index($_zones,"jsblacklist, ")<0)
setpref(STRING, "capability.policy.policynames", $_zones."jsblacklist, ");
if (index($_zones,"jswhitelist, ")<0)
setpref(STRING, "capability.policy.policynames", $_zones."jswhitelist, ");


Quote
siria
Quote
JamesD
#========================= AT STARTUP

# MINE, probably from testing Policies-Manager: Trusted-Sites, test, wideopen
BUG: setpref(STRING, "capability.policy.policynames", "jswhitelist, jsblacklist, Trusted-Sites, test, wideopen, ");
#setpref(STRING, "capability.policy.policynames", "jsblacklist");

Please James, the red line deletes a users's existing list, replace it in your posting with the 3-blue-lines-fix, thanks...


James, if you really fixed it on your "fork" too (what I have some doubts about), you can always post your updated version in a NEW POST, no prob, just please delete the OLD buggy version in the post above!



Edited 3 time(s). Last edit at 07/22/2011 11:53AM by siria.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: siria
Date: July 22, 2011 06:47AM

Marked a typo in red:

Quote
JamesD
$_JS_Blacklist= getpref(STRING, "capability.policy.jsblacklist.sites" );
$_JS_Origlist = getpref(STRING, "capability.policy.jsblacklist.sites" );
alert(length($_JSBlacklist), "Length of $_JSBlacklist DEBUG", INFO);
alert(length($_JS_Origlist), "Length of $_JS_Origlist DEBUG", INFO);

The code above gives two different lengths. The second read is one less than the first. Can anybody confirm that it is not just me?


Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: snuz2
Date: July 22, 2011 07:26AM

the problem with displaying text in the status bar is that it tends to disappear when you move the cursor. or some other unknown macro overwrites it. it would be nice if someone would write a plugin that would allow icons on the status bar like the popup blocked icon ( although it is ugly ).

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: JamesD
Date: July 22, 2011 11:52AM

@ siria

Yes, another typo. Thanks
I should never work that late at night. That means there is no bug in 1.7 but there is a problem in my macro.

@ snuz2

If something were put in a bar, could the macro force a change when user clicks on a different (already loaded) tab? There is event 'OnOpenTab' but I am not sure that happens simply by moving to a tab.

P.S. I removed the code.

Shall I continue in this thread with my code, or shall I open another thread? There is no real change in the subject.

Options: ReplyQuote
Re: javascript policies by website [BUGGY]
Posted by: JamesD
Date: July 22, 2011 10:23PM

I decided to carry on with this thread.

This is a macro inspired by siria. She had done some work on the subject of Javascript and the 'capability.policy' prefs. She decided not to use her work as there were some unfinished parts.

I have a need to have available to me some system to control the 'capability.policy' prefs in KM 1.7 or perhaps a later version. Right now the Policy Manager extension will not run in KM 1.7 KM 1.7 is alpha code and a later version may support Policy Manager. This something that I can use in the interim.

JSPoliciesList.kmm creates two policies, jswhitelist and jsblacklist, and assigns them the javascript capability of 'allAccess' and 'noAccess'. The user can toggle the domain of the current page's URL on or off either list. The lists can be viewed/edited, and within a session a list may be reset to the value it had at the start of the session.

Since I do not use the privacy bar, I have included code to show a flag for the default Javacript value. You may think the colors are backward, but I look at having no Javascript as safe i.e. green flag button, and allowing Javascript to run as unsafe i.e. red flag button. Clicking on the button can toggle the Javascript default.

Pardon the variable names, but the code came from various places and I have not had time to go back and enforce a correct naming standard.

JSPoliciesList.kmm can downloaded from:
http://dl.dropbox.com/u/1522294/JSPoliciesList.7z

You will also need the picture for the button. You can get it here:
http://dl.dropbox.com/u/1522294/Flip_PM.bmp
Copy the button file to Kmeleon/skins/default.

Comments and suggestions are welcome.

Options: ReplyQuote
Pages: 12Next
Current Page: 1 of 2


K-Meleon forum is powered by Phorum.