General :
K-Meleon Forum
Specific reasons?
Well, people who don't have problems live happy, that's sure.
I was retrying to import all again to 1.6b2 as I have to accept that I won't be able to use 1.1.x more time.
And the first annoyance and I complained before about: convert my new macro files to UTF8, because I can't UTF8 kmm files on previous versions, are they don't work.
After all, remove double quotes " because now it's "very important" to use just single quote ', so when you make a javascript function and javascript request to use double quotes instead single quotes, you now have to change to double single quotes (insane).
I know this is necessary to macro language to work, and you'll say that this is a rant, a mad rant. And I admit, but these things make me mad.
Ok, fixing, fixing and fixing, waste of a good of time with several tries and errors.
Now, I have a quite interesting problem (!!).
I have the macro below to change colors on some pages and make more comfortable to read.
As lately I browse with javascript disabled, I made "a trick" to enable javascript, run the injectJS function, and disable again javascript. It was working like a charm with 1.1.x 1.5.x. Why not on 1.6b2? No idea. But, worst, others that work the same way, I don't know if it is because they are called by menu, but works. This is related to that bug to not being able to use some accelerators? No idea.
Well, the macro I said above, just only if someone would like to help:
On bold "the trick".
EDIT:
Oh, more of those non-specific reasons. Crash, crash, crash. I told of this errors, and others made it too. But, why 1.6b2 gets stuck on 100% CPU load for no reason and the only way to continue is to hard-close it? I had this problem, from yesterday... mmmm... very often. I couldn't say how many times.
Edited 2 time(s). Last edit at 08/30/2011 01:49PM by jsnj.
Have no real probs with hanging. Javascript is mostly blocked, and plugins mostly too, except for occasional videos. When sometimes a window is unresponsive, I switch to another window and right back again and the window is responsive again. There IS some prob with javascripts not being stoppable yet. Guess that's one of the bugs that need fixing yet before a stable version will be published.
Thinking about it, there's a quite dim memory, but wasn't that 100% CPU thing related to some plugin??
UTF8 is running fine on KM1.5 already, that's not a KM1.6 thing. Besides, converting a file from ANSI to UTF8 sure isn't a prob for someone like you.
Sure you can use double quotes in scripts, if you add a \ before them: \"
Frankly, I find it hard to imagine that in former times scripts were working without that \ before doublequotes, but they definitely didn't run without it in KM1.5 either.
Your suspicion that some scripts only run if called by menu may well be true, the newer gecko seems to have much stricter 'security' restrictions :-( For example cross-domain stuff seems to be blocked and haven't read a solution yet how that might be allowed.
Regarding your macro lines, sorry no idea if this helps, but can't harm to try with the default commands from main.kmm:
"$jscript" is there "$pref_JavaScript"
"&JSToggle" is called "&pref_ToggleJavaScript"
By the way, since your example script is only changing styles, there's a good chance it may even run without unblocking javascript (I'm talking the 'normal' JS block from the priv-menu here, not that deadly CAPS-blocking thing)
Anyway, the real BIG probs I've run into myself often that's how newer gecko engines handles javascript. Have struggled an awful lot with longer injectJS codes in my macros, sometimes found workarounds and sometimes not, but am afraid there's not much to do about it from the developers side :-(
I'm using the old way, that's because is $jscript instead $pref_JavaScript (I still use the old macros because they do the same as the newer, just they are defined in a different way). The same thing for the macro "functions".
The only one harmed here are few little lines of "duplicated" macro code. I carried those macros from the first versions and, while they do the same, I don't touch them. I simple don't want to edit each macro to match other.
:-? I need explanation on that. This is at my wish, not using usercontent.css or similar...
Edited 3 time(s). Last edit at 08/29/2011 03:17AM by JohnHell.
There's an automatic exception rule for injectJS, as long as the js commands inside are of the less 'dangerous' sort (just my guess, but from experience).
Edited 1 time(s). Last edit at 08/29/2011 04:11AM by siria.
Found a test page
Am testing via macro javascriptia, to avoid a hundred restarts. And I need to split JS code into lines, or don't understand even what little I understand of it. Anyway, this way your code actually works in this very forum, but only if I add "kmbody();" at the end of it. JS-block doesn't seem to matter.
But not sure if it works on ALL pages... At first I thought this were something for frame pages, and took jujulands site for testing. And there it does nothing. But this could be restriction of javascriptia, can't remember if it was coded for frame pages...
num++;}}kmbody();");
Edited 5 time(s). Last edit at 08/29/2011 04:32AM by siria.
Sorry, I must be getting dumb with the age.
What option in privacy menu? I thing I don't have the same privacy menu :-?
Are we talking about an option below Tools > Privacy?
Let met explain better... The macro is being called through an accelerator shortcut and its purpose is to change the background of everything and remove background images also, as well as put the text in black.
The macro, of course, and if what is not happening on 1.6b2, must work under a non javascript enabled environment...
NOTE: I understand what you are doing with the JS, but... that has nothing to do with what I was trying to say. Javascript disabled, I enable, I inject js, I run, I disable javascript.
4th edit
this macro IS NOT SITE SPECIFIC.
Edited 4 time(s). Last edit at 08/29/2011 05:40AM by JohnHell.
About the CPU usage, I know I didn't answered, but happened again.
Just visiting the forum, went to my youtube inbox and... booom.
What I did? Open the Error Console, but this is not the cause of the CPU usage, it happens without open it.
Why I opened the Error Console. Easy. Just to try to capture what I saw yesterday (I had opened when the CPU usage go to the moon).
What I saw? A kind of loop. Related to the page, but I can't remember exactly.
In some way I think could be a mistake with JIT (trying to run something several times). But as it is totally random... I can't test all the way someone would like.
I'm saying this to demonstrate is not related to plugins (if there are plugins in the youtube inbox page loaded, I don't know, but they can load as I have everything blocked).
Edited 2 time(s). Last edit at 08/29/2011 05:59AM by JohnHell.
Obviously. There's no URL in it. So it works on all tested non-frame pages for me. Just simply the injectJS line, no tricks, no JS-toggle needed. Not sure though if your 5-year-outdated toggles still are supported a couple versions later. Or if error console also finds macro errors in macro-legacy-mode? It works quite well to find probs in the current macro system.
Edited 1 time(s). Last edit at 08/29/2011 02:10PM by siria.
I would like to chat with you to have a better explanation, really.
You are not understanding me and I don't understand you. What you did with the code, doesn't work with me (indeed is the same code by me, but called in a different way) and I don't understand what you did to make it work without javascript enabled. I asked what option of privacy menu and you didn't reply. What is CAPS?
I feel like a newbie :S but because I know I'm missing something and I don't get it :-?
And all around new KM versions that make me mad is not helping
And forget the age of the macros. I said is the same code, and does the same, just
is defined in a different way.
There are cosmetic changes but they are the same. New against old:
There are no errors at all in the console (don't mix what I said about the error console above about 100% cpu usage, that has nothing to do with this macro). There are no errors, apart those by the page itself.
If you consider an MSN session or something, tell me.
CAPS stands for capability policy. Policy Manager uses CAPS.
CAPS is different from the Javascript item in PREFERENCES.
I get past the CAPS policy for local items by noting and, if needed, quickly changing the CAPS policy. See example of one of my changes to KM main.kmm file.
The $FlipFlip lines read the policy and if it is "noAccess" then they toggle the policy to "allccess", run the original code, and return the policy to the way is was.
Ok, that was clearer, but, what has CAPS to do here? (I don't visit the forum very often but I read you discussing something)
In other words, what is the default value for capability.policy.default.javascript.enabled? Is set to noAccess?
From what it says here, javascript.enable value is over policies. Do I still need to play with that capability.policy.default.javascript.enabled pref?
Isn't this a bug of the beta? The same macros called from right click menu work!!!
Ok, I found "the problem".
Even, as I said, Siria's change to JS was logic, it still didn't work for me. The reason is unknown.
My macro wasn't special, I just call injectJS to inject my own javascript and then I call the JS function via a "URL" call through "javascript:kmbody();". Nothing special, nothing strange. This is accepted on previous versions of K-meleon.
If this is a problem with the new GRE or if this a problem of K-meleon, I leave it to the developers.
The way it works is to use what I avoided (the reason, I can't remember): hndlDocs (the old macro) or JS_hndlDocs (the new declaration (as with the jstoggle function, is just the new definition)) and, therefore, call the JS function "kmbody();" through JSdoit (or JS_doit in the new declaration way).
As I said, I leave this to the developers but, why now is not accepted "javascript:whatever_function_to_run();" as URL?
May be that K-meleon now runs too fast the code and disables javascript before I call a URL like "javascript:whatever_function_to_run();"? I disabled JIT, just to test, and wasn't that, so, why happens?
I say this because if I run manually on a page that has the JS function (not injected) "javascript:whatever_function_to_run();" works as an URL.
I ask not to fix, but for pure knowledge. Knowledge of those annoyances, by the new GRE, or K-meleon, I just don't care, because they continue being annoyances.
As those that you have to click on a page before doing something, because it has no focus or whatever, or how the mouse disappears when you type in the URL bar (probably related to crashes when you type some letters on the URL), etc, etc, etc.
Specific reasons?, as you asked... well, I don't know. I simply don't like the behavior of this new version. As I didn't like some annoyances of 1.5.x in the past. I just feel that before 1.5.x, K-meleon was "the browser you control", now is the browser that you have to tame/break before you start to control, if someday that comes to happen.
I know I'm ranting in an infinite loop but I don't like these annoyances whatever comes from GRE or the new K-meleon itself.
Edited 1 time(s). Last edit at 08/30/2011 02:01AM by JohnHell.
If you do not use Policy Manager, it is unlikely that you will have CAPS prefs on your system. It is easy to check for them. Just open your 'pref.js' file in Notepad and do a find on 'capability'. If you don't find it, then you are not using CAPS.
The reason my system has noAccess for the default is that I have Javascript enabled in PREFERENCES but only allow Javascript for URLs in an approved list within Policy Manager. I have a button which is green (safe) when the default is noAccess and red (unsafe) when I toggle the pref to be allAccess. This lets me bypass the whole privacy bar thing.
Oh my, that's just way too long and complicated to discuss everything...
But I guess the main problem is just that you insist on using stoneage macros.cfg for all eternity, struggling for hundreds of hours and getting a hundred gray hears, instead of finally giving in and spending some ten hours in transfering your macros.cfg into a JohnHell.kmm file
Oh well. Lets still see some of the points: Those little bugs that you mention like needing to click in a page or such, that's just that, beta bugs. Due to new gecko. First dorian fixed some, then desga, currently deadlock. You know yourself this is still a slightly buggy beta version, so no reason to condemn all KM versions younger than 1.0 generally as unhandable. Those bugs are due to beta state, wait with condemning until the next stable version is out, if it still contains those bugs But frankly, I have hardly ever trouble with that stuff. It happens rarely and I know how to work around in seconds, so no stress. BTW my mouse does not disappear when typing in the URL bar.
What I changed to enable javascript? Really nothing. What I tried to tell 3 times already: there is nowadays a built-in exception rule for the injectJS command. JS is toggled automatically if an injectJS is fired. But with those exceptions allowing only less dangerous commands, like zooming or changing css styles, page titles and such. You can simply delete the JStoggle lines for the given example script. Well, this goes of course for my "current" macro system, no idea if it also goes for sort of "legacy macro emulation" on new KM versions. That may not work anymore 100% perfect 5 years later.
About CAPS policies: Yep, as James said too, if you don't use Policy Manager, it's almost sure you don't need to think about CAPS stuff.
Okay, I digged up an old 1.0x version of mine and looked inside macros.cfg, to see which pref it really toggles. And it's still the same as today. No caps, no worries. So forget that I mentioned caps.
Sure it is But only if you have javascript fully enabled, otherwise "javascript:" in URL bar is blocked. And it also doesn't work from urlbar if the setting to "open Typed URLs" is set to open "in a new page".
I also suspect, if you have the "define kmbody" and the "execute kmbody" split up into two separate actions, and JS is toggled on-off-on-off, the script may well be killed in the middle, and the definition of kmbody forgotten again. So would much rather leave it "in one piece" in one injectJS line.
So, the question is what happens if you only keep the extended js-line, delete the toggle lines, restart KM, allow JS manually, then run the macro? Does it work at all if JS is fully allowed?? If not, I'm going to blame your legacy mode No, not the single commands in it, but the whole system in itself with macros.cfg and such. You'd really save a lot of time and gray hairs the quicker you switch to the modern macro version, and get tons of *working* new macros at that ;-)
Edited 3 time(s). Last edit at 08/30/2011 03:03AM by siria.
Again, and it's the last one. Old macros = new macros with different definition styles. They do exactly the same. So I'm not going to discuss on this topic anymore
I know, and that is why I find less than funny to find asking what reasons are to still using old versions.
But I find interesting how people don't have problems with it and find workarounds. When K-meleon gets stuck at 100% CPU load and the only way to continue using it is close it... what is the workaround? Please, tell me, because, right now, this is the most annoying thing with 1.6b2.
About the URL bar typing, I'm going to make a video, as I did in the past to compare a bug from one to other version. Then, tell me.
The first time I hear there is no need to enable javascript to use injectJS. Really, it's not a joke. In 8 years, the first time.
And, hey!, it's true. How is that no one told me before?!?!
I know the answer, and I don't want to hurt the feelings of anyone, seriously: the lack of a good documentation and the lack of the people who know how it works that don't change the documentation accordingly, what doesn't help. (Sadly, a lot of people disappeared from this page/project/piece of software)
If this (injectJS working without javascript enabled) is being said somewhere, please, tell me. I'll admit any error by myself.
But you told me. You assumed I was using it. Why?
But I don't toggle on-off continuously. Have a look, again, to my code. I just toggle on, inject code, let run code, toggle off.
Never, never, can this kill a script. Unless the toggle off is being run before wait until script finishes. This behavior is correctly made by 1.1.x, why not in 1.6b2?
Again, this is not with macro version (is not even macro, but definition).
What do you have against old macro definition if they do exactly the same?
I know, when I try to search for help you can get confused. I accept it. But, in the other hand, I don't get why the main macro definition (that, indeed, are inside main.kmm) got changed by the developers. What's wrong with them????
Well, let's make the video about mouse disappearing when you type in the URL bar.
EDIT: ummmm not video, looks like this happens on previous version but I didn't noticed before LOL... Probably my bad eye over 1.6b2, blinded me over the truth
But I found 1.6b2 closed while I was typing in the URL bar LOL. Do you like to see that video?
EDIT2: It is a documented crash, but just for the fun:
http://www.megaupload.com/?d=XAF2ZMO6
Edited 2 time(s). Last edit at 08/30/2011 04:38AM by JohnHell.
Hey, cool video! No idea how you managed that, never happened to me. Perhaps the special characters somehow? Not really, if enter wasn't pressed, huh? But it's known that there are some bugs with urlbar in 1.6beta. Just not such spectacular crashes live on video, LOL! PS: deadlock figured out just days ago that in certain cases it's due to huge history files.
How come I have a hard time believing you "exactly the same"? Ah yes - because the very same code lines work fine in a "normal" macro environment and not in a "legacy emulation" environment?? That's the only difference, or do you know another? If the code itself is the same?
There's a wide range between 1.0 emulation and 1.6beta E.g. KM154 works quite well, apart from the increasing "outdated gecko" probs. But in yet older versions those probs certainly are more, not less.
Happens too rarely to me, and then mostly when I have some 30 tabs open in my oldie machine with 256MB RAM. My fault. And when 1.6beta gets stuck due to some script, I toggle windows for a second and it'S responsive again. As written before, I do have less plugins than others (no java for example), and usually all sorts of stuff blocked, incl. "DOMstorage" and "embedded objects". Hmm, when I think hard, there returns a memory about some fancy-blinky forum that used to kill KM if JS was on, but that was long before the first 1.6 version. Finally figured out it had to do with some stuff from "ajax.googleapis.com", blocked that in windows HOSTS file, and prob was gone But the bug as you describe it exactly is rather unknown to me, sorry. Yeah it does exist, have read about it from others too in this forum.
Uffff.... ONE point gotten across, can't believe it, LOL!
No idea if it's written somewhere, I just noticed it some day. Took me just awhile to realize why it worked sometimes and other times not! Ah yes, guess I actually mentioned it myself a few times in the forum, when the subject was policy manager and the infamous caps policies. Then again, perhaps was only implying it, when posting that many default functions are blocked when using CAPS-JS-block, can't remember exactly,
Yeah, it would easier be found on macrolanguage2 page. But frankly, how often and thoroughly you study that one??
About CAPS policies:
I didn't "assume" you use it, but it wasn't completely impossible, so better mention it too. It's one of two ways to block JS in gecko, and had no idea (before digging up my 1.0x version) which one a stoneage KM had used by default. Still possible that some macro uses it, but not very likely.
At first, yes, but then you posted about "javascript:whatever_function_to_run();" as URL. So that sounds as injecting the last part via URLbar now instead of via injectJS. If that was just a misunderstanding, all the better.
It does work in 1.6b2, must be some other reason in your setup... BTW you mentioned jit, that's also one of the things I've disabled on my oldie machine.
Oh nothing. Just can't help getting the impression that they don't quite exactly do the same in our 1.6b2 browsers. It works on mine. It works not on yours. "Exactly the same"?? *whistle*
Edited 1 time(s). Last edit at 08/30/2011 06:37AM by siria.
Nop, I don't hit enter in the video. I just typed randomly to show how the mouse is hidden and then I deleted with backspace and type a real url. I was going to type www.google.com, but after the dot, when I typed g... stopped and crash, well, close, not crash, to be fair.
May be the history. It is just only ~7MB (2 months).
(The blurry is a video edition to hide my desktop and bookmarks toolbar)
I don't get your differentiation between normal macro and legacy emulation, as if it wasn't built-in the same macro language supporting the same commands :-?
Are you just making fun?
In other words, a big deal to stability.
I had a look in the past, but as I don't use newer versions of KM, why bother studying it?
By the way, do you mean this page?
In my first post my macro said "open("javascript:kmbody();");", or, in other words, I'm calling the script via URL, but is totally legal And it was before disable javascript. So no harm.
My setup? I'll test on a new profile (I used to do), but I don't know what I could have on my setup :-?
I tested with both, enabled and disabled, JIT.
EDIT before posting: in a new profile is the same behavior, is not accepted the URL "javascript:whatever();". It is as javascript is being disabled before let the URL call to the function to work.
As I said, this doesn't happen on previous versions.
But wasn't the macro definition itself, but the call to the JS function. I did through URL instead hndlDocs. On 1.6b2, didn't work, on previous, did. If I'd use hndlDocs from the first time, it would work on 1.6b2, but that is not the story
Again, it works in 16b2 (for other configurations than yours).
Another little test, check if this works:
- Allow javascript
- Make sure in F2 that your setting for "Typed URLs" is to open in the CURRENT page
- Paste this line and hit enter:
javascript: function kmbody(){var body;var num = 0; var cuantos; body = document.getElementsByTagName('*'); cuantos = document.getElementsByTagName('*').length; while(num<cuantos){ body[num].style.backgroundImage = 'url(none)'; body[num].style.backgroundColor = '#858585'; body[num].style.color = '#000000'; if(body[num].href){body[num].style.backgroundColor = '#808090'} num++; } } kmbody();
Guess that's without using macrolanguage, but you say your urlbar doesnt accept it either. Mine works fine this way too.
(And try shorten your history a bit? 7MB is quite a lot for a URL collection!! But you can insist on keeping it eternally, and not even test with a smaller one, just thought you had complained how much it bugs you that 16beta is closing/crashing so often Who knows - perhaps that history bug is also responsible for other weird crashes?? Can only tell that it happens extremely rarely to my, and my history is quite short)
Edited 2 time(s). Last edit at 08/30/2011 01:07PM by siria.
PS: Suggestion to split this thread into a youtube one and a macro versions one?
No, doesn't work.
Yes, does work. But only if you remove the enable/disable javascript trick. I was sleepy and I didn't bother to edit to say that your macro edit involved remove the enable/disable trick.
Yours works.
Edited 2 time(s). Last edit at 08/30/2011 09:54PM by JohnHell.
It works?! Fine
If you think that the old js toggle has a bug, try if it works after removing &PrivacySync from the toggle. When I took a look into my ancient macros.cfg I noticed surprised that it uses "setcheck" for the priv-macros, but IIRC had tried that awhile ago and found it doesn't work for macros, then had suspected it's probably meant for ID-commands only, but not sure at all. Might very well confuse the commands and this is all nonsense. Anyway, worth a short test if you want to use that toggle for other scripts (which may contain other js commands without exception permission)
Edited 2 time(s). Last edit at 08/30/2011 11:57PM by siria.
Funny image: cookies everywhere.
I don't know what is worst. Have K-meleon windows locked because a cookie window message, or have them unlocked but a lot of cookie windows...
This happened the other day and was quite funny.
Note: I placed the windows just to show the mess. Usually you won't notice the creation of this bunch of windows, but I did.
Edited 2 time(s). Last edit at 09/08/2011 01:28AM by JohnHell.
General discussion about K-Meleon.
Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 28, 2011 11:06PM
Specific reasons?
Well, people who don't have problems live happy, that's sure.
I was retrying to import all again to 1.6b2 as I have to accept that I won't be able to use 1.1.x more time.
And the first annoyance and I complained before about: convert my new macro files to UTF8, because I can't UTF8 kmm files on previous versions, are they don't work.
After all, remove double quotes " because now it's "very important" to use just single quote ', so when you make a javascript function and javascript request to use double quotes instead single quotes, you now have to change to double single quotes (insane).
I know this is necessary to macro language to work, and you'll say that this is a rant, a mad rant. And I admit, but these things make me mad.
Ok, fixing, fixing and fixing, waste of a good of time with several tries and errors.
Now, I have a quite interesting problem (!!).
I have the macro below to change colors on some pages and make more comfortable to read.
As lately I browse with javascript disabled, I made "a trick" to enable javascript, run the injectJS function, and disable again javascript. It was working like a charm with 1.1.x 1.5.x. Why not on 1.6b2? No idea. But, worst, others that work the same way, I don't know if it is because they are called by menu, but works. This is related to that bug to not being able to use some accelerators? No idea.
Well, the macro I said above, just only if someone would like to help:
alto_contraste{
$jsison = getpref(BOOL,$jscript);
$jsison == false ? &JSToggle : 0 ;
injectJS("function kmbody(){var body; var num = 0; var cuantos; body = document.getElementsByTagName('*'); cuantos = document.getElementsByTagName('*').length; while(num<cuantos){body[num].style.backgroundImage = 'url(none)'; body[num].style.backgroundColor = '#858585'; body[num].style.color = '#000000'; if(body[num].href){body[num].style.backgroundColor = '#808090'} num++;}}");
open("javascript:kmbody();");
$jsison == false ? &JSToggle : 0 ;
}
On bold "the trick".
EDIT:
Oh, more of those non-specific reasons. Crash, crash, crash. I told of this errors, and others made it too. But, why 1.6b2 gets stuck on 100% CPU load for no reason and the only way to continue is to hard-close it? I had this problem, from yesterday... mmmm... very often. I couldn't say how many times.
Edited 2 time(s). Last edit at 08/30/2011 01:49PM by jsnj.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 29, 2011 01:41AM
Have no real probs with hanging. Javascript is mostly blocked, and plugins mostly too, except for occasional videos. When sometimes a window is unresponsive, I switch to another window and right back again and the window is responsive again. There IS some prob with javascripts not being stoppable yet. Guess that's one of the bugs that need fixing yet before a stable version will be published.
Thinking about it, there's a quite dim memory, but wasn't that 100% CPU thing related to some plugin??
UTF8 is running fine on KM1.5 already, that's not a KM1.6 thing. Besides, converting a file from ANSI to UTF8 sure isn't a prob for someone like you.
Sure you can use double quotes in scripts, if you add a \ before them: \"
Frankly, I find it hard to imagine that in former times scripts were working without that \ before doublequotes, but they definitely didn't run without it in KM1.5 either.
Your suspicion that some scripts only run if called by menu may well be true, the newer gecko seems to have much stricter 'security' restrictions :-( For example cross-domain stuff seems to be blocked and haven't read a solution yet how that might be allowed.
Regarding your macro lines, sorry no idea if this helps, but can't harm to try with the default commands from main.kmm:
"$jscript" is there "$pref_JavaScript"
"&JSToggle" is called "&pref_ToggleJavaScript"
By the way, since your example script is only changing styles, there's a good chance it may even run without unblocking javascript (I'm talking the 'normal' JS block from the priv-menu here, not that deadly CAPS-blocking thing)
Anyway, the real BIG probs I've run into myself often that's how newer gecko engines handles javascript. Have struggled an awful lot with longer injectJS codes in my macros, sometimes found workarounds and sometimes not, but am afraid there's not much to do about it from the developers side :-(
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 29, 2011 03:14AM
Quote
siria
Regarding your macro lines, sorry no idea if this helps, but can't harm to try with the default commands from main.kmm:
"$jscript" is there "$pref_JavaScript"
"&JSToggle" is called "&pref_ToggleJavaScript"
I'm using the old way, that's because is $jscript instead $pref_JavaScript (I still use the old macros because they do the same as the newer, just they are defined in a different way). The same thing for the macro "functions".
The only one harmed here are few little lines of "duplicated" macro code. I carried those macros from the first versions and, while they do the same, I don't touch them. I simple don't want to edit each macro to match other.
Quote
By the way, since your example script is only changing styles, there's a good chance it may even run without unblocking javascript (I'm talking the 'normal' JS block from the priv-menu here, not that deadly CAPS-blocking thing)
:-? I need explanation on that. This is at my wish, not using usercontent.css or similar...
Edited 3 time(s). Last edit at 08/29/2011 03:17AM by JohnHell.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 29, 2011 03:54AM
There's an automatic exception rule for injectJS, as long as the js commands inside are of the less 'dangerous' sort (just my guess, but from experience).
Edited 1 time(s). Last edit at 08/29/2011 04:11AM by siria.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 29, 2011 04:13AM
Found a test page
Am testing via macro javascriptia, to avoid a hundred restarts. And I need to split JS code into lines, or don't understand even what little I understand of it. Anyway, this way your code actually works in this very forum, but only if I add "kmbody();" at the end of it. JS-block doesn't seem to matter.
But not sure if it works on ALL pages... At first I thought this were something for frame pages, and took jujulands site for testing. And there it does nothing. But this could be restriction of javascriptia, can't remember if it was coded for frame pages...
Change the ending to:Quote
JohnHell
injectJS("function kmbody(){var body; var num = 0; var cuantos; body = document.getElementsByTagName('*'); cuantos = document.getElementsByTagName('*').length; while(num<cuantos){body[num].style.backgroundImage = 'url(none)'; body[num].style.backgroundColor = '#858585'; body[num].style.color = '#000000'; if(body[num].href){body[num].style.backgroundColor = '#808090'} num++;}}");
num++;}}kmbody();");
Edited 5 time(s). Last edit at 08/29/2011 04:32AM by siria.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 29, 2011 05:30AM
Sorry, I must be getting dumb with the age.
What option in privacy menu? I thing I don't have the same privacy menu :-?
Are we talking about an option below Tools > Privacy?
Let met explain better... The macro is being called through an accelerator shortcut and its purpose is to change the background of everything and remove background images also, as well as put the text in black.
The macro, of course, and if what is not happening on 1.6b2, must work under a non javascript enabled environment...
NOTE: I understand what you are doing with the JS, but... that has nothing to do with what I was trying to say. Javascript disabled, I enable, I inject js, I run, I disable javascript.
4th edit
this macro IS NOT SITE SPECIFIC.Edited 4 time(s). Last edit at 08/29/2011 05:40AM by JohnHell.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 29, 2011 05:58AM
About the CPU usage, I know I didn't answered, but happened again.
Just visiting the forum, went to my youtube inbox and... booom.
What I did? Open the Error Console, but this is not the cause of the CPU usage, it happens without open it.
Why I opened the Error Console. Easy. Just to try to capture what I saw yesterday (I had opened when the CPU usage go to the moon).
What I saw? A kind of loop. Related to the page, but I can't remember exactly.
In some way I think could be a mistake with JIT (trying to run something several times). But as it is totally random... I can't test all the way someone would like.
I'm saying this to demonstrate is not related to plugins (if there are plugins in the youtube inbox page loaded, I don't know, but they can load as I have everything blocked).
Edited 2 time(s). Last edit at 08/29/2011 05:59AM by JohnHell.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 29, 2011 01:56PM
Quote
JohnHell
this macro IS NOT SITE SPECIFIC.
Obviously. There's no URL in it. So it works on all tested non-frame pages for me. Just simply the injectJS line, no tricks, no JS-toggle needed. Not sure though if your 5-year-outdated toggles still are supported a couple versions later. Or if error console also finds macro errors in macro-legacy-mode? It works quite well to find probs in the current macro system.
Edited 1 time(s). Last edit at 08/29/2011 02:10PM by siria.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 29, 2011 09:41PM
I would like to chat with you to have a better explanation, really.
You are not understanding me and I don't understand you. What you did with the code, doesn't work with me (indeed is the same code by me, but called in a different way) and I don't understand what you did to make it work without javascript enabled. I asked what option of privacy menu and you didn't reply. What is CAPS?
I feel like a newbie :S but because I know I'm missing something and I don't get it :-?
And all around new KM versions that make me mad is not helping
And forget the age of the macros. I said is the same code, and does the same, just
is defined in a different way.
There are cosmetic changes but they are the same. New against old:
pref_ToggleJavaScript{
macroinfo=_("Toggle JavaScript execution");
menuchecked=!getpref(BOOL,$pref_JavaScript);
togglepref(BOOL,$pref_JavaScript); &_pref_SyncButtons;
statusbar(sub("%s",!getpref(BOOL,$pref_JavaScript)?$off:$on,_("JavaScript execution %s")));
}
JSToggle{
togglepref(BOOL,$jscript); &PrivacySync;
statusbar(sub("%s",getpref(BOOL,$jscript)==false?$OFF:$ON,_("JavaScript execution %s")));
}
There are no errors at all in the console (don't mix what I said about the error console above about 100% cpu usage, that has nothing to do with this macro). There are no errors, apart those by the page itself.
If you consider an MSN session or something, tell me.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JamesD
Date: August 30, 2011 12:29AM
Quote
JohnHell
What is CAPS?
CAPS stands for capability policy. Policy Manager uses CAPS.
user_pref("capability.policy.default.javascript.enabled", "noAccess");
user_pref("capability.policy.default.javascript.enabled", "allAccess");
CAPS is different from the Javascript item in PREFERENCES.
javascript.enabled boolean true/false
I get past the CAPS policy for local items by noting and, if needed, quickly changing the CAPS policy. See example of one of my changes to KM main.kmm file.
JS_hndlTop{
# Same as JS_hndlDoc, but only for the topmost frame (to avoid cross site scripting).
$FlipFlip = false;
getpref( STRING, "capability.policy.default.javascript.enabled")=="noAccess" ? $FlipFlip=true : 0 ;
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
injectJS("(function(){".$JS_func.$_JS_urlencode."with(document){".$JS_doit."}".$JS_last."})()");
$FlipFlip == true ? togglepref( STRING, "capability.policy.default.javascript.enabled", "noAccess", "allAccess") : 0;
$JS_doit=""; $JS_func=""; $JS_last=""; $JS_fail="";
}
The $FlipFlip lines read the policy and if it is "noAccess" then they toggle the policy to "allccess", run the original code, and return the policy to the way is was.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 30, 2011 01:59AM
Ok, that was clearer, but, what has CAPS to do here? (I don't visit the forum very often but I read you discussing something)
In other words, what is the default value for capability.policy.default.javascript.enabled? Is set to noAccess?
From what it says here, javascript.enable value is over policies. Do I still need to play with that capability.policy.default.javascript.enabled pref?
Isn't this a bug of the beta? The same macros called from right click menu work!!!
Ok, I found "the problem".
Even, as I said, Siria's change to JS was logic, it still didn't work for me. The reason is unknown.
My macro wasn't special, I just call injectJS to inject my own javascript and then I call the JS function via a "URL" call through "javascript:kmbody();". Nothing special, nothing strange. This is accepted on previous versions of K-meleon.
If this is a problem with the new GRE or if this a problem of K-meleon, I leave it to the developers.
The way it works is to use what I avoided (the reason, I can't remember): hndlDocs (the old macro) or JS_hndlDocs (the new declaration (as with the jstoggle function, is just the new definition)) and, therefore, call the JS function "kmbody();" through JSdoit (or JS_doit in the new declaration way).
As I said, I leave this to the developers but, why now is not accepted "javascript:whatever_function_to_run();" as URL?
May be that K-meleon now runs too fast the code and disables javascript before I call a URL like "javascript:whatever_function_to_run();"? I disabled JIT, just to test, and wasn't that, so, why happens?
I say this because if I run manually on a page that has the JS function (not injected) "javascript:whatever_function_to_run();" works as an URL.
I ask not to fix, but for pure knowledge. Knowledge of those annoyances, by the new GRE, or K-meleon, I just don't care, because they continue being annoyances.
As those that you have to click on a page before doing something, because it has no focus or whatever, or how the mouse disappears when you type in the URL bar (probably related to crashes when you type some letters on the URL), etc, etc, etc.
Specific reasons?, as you asked... well, I don't know. I simply don't like the behavior of this new version. As I didn't like some annoyances of 1.5.x in the past. I just feel that before 1.5.x, K-meleon was "the browser you control", now is the browser that you have to tame/break before you start to control, if someday that comes to happen.
I know I'm ranting in an infinite loop but I don't like these annoyances whatever comes from GRE or the new K-meleon itself.
Edited 1 time(s). Last edit at 08/30/2011 02:01AM by JohnHell.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JamesD
Date: August 30, 2011 02:26AM
Quote
JohnHell
In other words, what is the default value for capability.policy.default.javascript.enabled? Is set to noAccess?
From what it says here, javascript.enable value is over policies. Do I still need to play with that capability.policy.default.javascript.enabled pref?
If you do not use Policy Manager, it is unlikely that you will have CAPS prefs on your system. It is easy to check for them. Just open your 'pref.js' file in Notepad and do a find on 'capability'. If you don't find it, then you are not using CAPS.
The reason my system has noAccess for the default is that I have Javascript enabled in PREFERENCES but only allow Javascript for URLs in an approved list within Policy Manager. I have a button which is green (safe) when the default is noAccess and red (unsafe) when I toggle the pref to be allAccess. This lets me bypass the whole privacy bar thing.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 30, 2011 02:54AM
Oh my, that's just way too long and complicated to discuss everything...
But I guess the main problem is just that you insist on using stoneage macros.cfg for all eternity, struggling for hundreds of hours and getting a hundred gray hears, instead of finally giving in and spending some ten hours in transfering your macros.cfg into a JohnHell.kmm file
Oh well. Lets still see some of the points: Those little bugs that you mention like needing to click in a page or such, that's just that, beta bugs. Due to new gecko. First dorian fixed some, then desga, currently deadlock. You know yourself this is still a slightly buggy beta version, so no reason to condemn all KM versions younger than 1.0 generally as unhandable. Those bugs are due to beta state, wait with condemning until the next stable version is out, if it still contains those bugs
But frankly, I have hardly ever trouble with that stuff. It happens rarely and I know how to work around in seconds, so no stress. BTW my mouse does not disappear when typing in the URL bar.
What I changed to enable javascript? Really nothing. What I tried to tell 3 times already: there is nowadays a built-in exception rule for the injectJS command. JS is toggled automatically if an injectJS is fired. But with those exceptions allowing only less dangerous commands, like zooming or changing css styles, page titles and such. You can simply delete the JStoggle lines for the given example script. Well, this goes of course for my "current" macro system, no idea if it also goes for sort of "legacy macro emulation" on new KM versions. That may not work anymore 100% perfect 5 years later.
About CAPS policies: Yep, as James said too, if you don't use Policy Manager, it's almost sure you don't need to think about CAPS stuff.
Okay, I digged up an old 1.0x version of mine and looked inside macros.cfg, to see which pref it really toggles. And it's still the same as today. No caps, no worries. So forget that I mentioned caps.
Quote
why now is not accepted "javascript:whatever_function_to_run();" as URL?
Sure it is
But only if you have javascript fully enabled, otherwise "javascript:" in URL bar is blocked. And it also doesn't work from urlbar if the setting to "open Typed URLs" is set to open "in a new page".
I also suspect, if you have the "define kmbody" and the "execute kmbody" split up into two separate actions, and JS is toggled on-off-on-off, the script may well be killed in the middle, and the definition of kmbody forgotten again. So would much rather leave it "in one piece" in one injectJS line.
So, the question is what happens if you only keep the extended js-line, delete the toggle lines, restart KM, allow JS manually, then run the macro? Does it work at all if JS is fully allowed?? If not, I'm going to blame your legacy mode
No, not the single commands in it, but the whole system in itself with macros.cfg and such. You'd really save a lot of time and gray hairs the quicker you switch to the modern macro version, and get tons of *working* new macros at that ;-)Edited 3 time(s). Last edit at 08/30/2011 03:03AM by siria.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 30, 2011 03:34AM
Quote
siria
Oh my, that's just way too long and complicated to discuss everything...
But I guess the main problem is just that you insist on using stoneage macros.cfg for all eternity, struggling for hundreds of hours and getting a hundred gray hears, instead of finally giving in and spending some ten hours in transfering your macros.cfg into a JohnHell.kmm file
Again, and it's the last one. Old macros = new macros with different definition styles. They do exactly the same. So I'm not going to discuss on this topic anymore
Quote
siria
Oh well. Lets still see some of the points: Those little bugs that you mention like needing to click in a page or such, that's just that, beta bugs. Due to new gecko. First dorian fixed some, then desga, currently deadlock. You know yourself this is still a slightly buggy beta version, so no reason to condemn all KM versions younger than 1.0 generally as unhandable. Those bugs are due to beta state, wait with condemning until the next stable version is out, if it still contains those bugs
I know, and that is why I find less than funny to find asking what reasons are to still using old versions.
But I find interesting how people don't have problems with it and find workarounds. When K-meleon gets stuck at 100% CPU load and the only way to continue using it is close it... what is the workaround? Please, tell me, because, right now, this is the most annoying thing with 1.6b2.
About the URL bar typing, I'm going to make a video, as I did in the past to compare a bug from one to other version. Then, tell me.
Quote
siria
What I changed to enable javascript? Really nothing. What I tried to tell 3 times already: there is nowadays a built-in exception rule for the injectJS command. JS is toggled automatically if an injectJS is fired. But with those exceptions allowing only less dangerous commands, like zooming or changing css styles, page titles and such. You can simply delete the JStoggle lines for the given example script. Well, this goes of course for my "current" macro system, no idea if it also goes for sort of "legacy macro emulation" on new KM versions. That may not work anymore 100% perfect 5 years later.
The first time I hear there is no need to enable javascript to use injectJS. Really, it's not a joke. In 8 years, the first time.
And, hey!, it's true. How is that no one told me before?!?!
I know the answer, and I don't want to hurt the feelings of anyone, seriously: the lack of a good documentation and the lack of the people who know how it works that don't change the documentation accordingly, what doesn't help. (Sadly, a lot of people disappeared from this page/project/piece of software
)
If this (injectJS working without javascript enabled) is being said somewhere, please, tell me. I'll admit any error by myself.
Quote
siria
About CAPS policies: Yep, as James said too, if you don't use Policy Manager, it's almost sure you don't need to think about CAPS stuff.
Okay, I digged up an old 1.0x version of mine and looked inside macros.cfg, to see which pref it really toggles. And it's still the same as today. No caps, no worries. So forget that I mentioned caps.
But you told me. You assumed I was using it. Why?
Quote
siria
Quote
why now is not accepted "javascript:whatever_function_to_run();" as URL?
Sure it is
I also suspect, if you have the "define kmbody" and the "execute kmbody" split up into two separate actions, and JS is toggled on-off-on-off, the script may well be killed in the middle, and the definition of kmbody forgotten again. So would much rather leave it "in one piece" in one injectJS line.
But I don't toggle on-off continuously. Have a look, again, to my code. I just toggle on, inject code, let run code, toggle off.
Never, never, can this kill a script. Unless the toggle off is being run before wait until script finishes. This behavior is correctly made by 1.1.x, why not in 1.6b2?
Quote
siria
So, the question is what happens if you only keep the extended js-line, delete the toggle lines, restart KM, allow JS manually, then run the macro? Does it work at all if JS is fully allowed?? If not, I'm going to blame your legacy mode
Again, this is not with macro version (is not even macro, but definition).
What do you have against old macro definition if they do exactly the same?
I know, when I try to search for help you can get confused. I accept it. But, in the other hand, I don't get why the main macro definition (that, indeed, are inside main.kmm) got changed by the developers. What's wrong with them????
Well, let's make the video about mouse disappearing when you type in the URL bar.
EDIT: ummmm not video, looks like this happens on previous version but I didn't noticed before LOL... Probably my bad eye over 1.6b2, blinded me over the truth
But I found 1.6b2 closed while I was typing in the URL bar LOL. Do you like to see that video?
EDIT2: It is a documented crash, but just for the fun:
http://www.megaupload.com/?d=XAF2ZMO6
Edited 2 time(s). Last edit at 08/30/2011 04:38AM by JohnHell.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 30, 2011 06:03AM
Hey, cool video!
No idea how you managed that, never happened to me. Perhaps the special characters somehow? Not really, if enter wasn't pressed, huh? But it's known that there are some bugs with urlbar in 1.6beta. Just not such spectacular crashes live on video, LOL! PS: deadlock figured out just days ago that in certain cases it's due to huge history files.
Quote
JohnHell
Old macros = new macros with different definition styles. They do exactly the same.
How come I have a hard time believing you "exactly the same"? Ah yes - because the very same code lines work fine in a "normal" macro environment and not in a "legacy emulation" environment?? That's the only difference, or do you know another? If the code itself is the same?
Quote
JohnHell
I know, and that is why I find less than funny to find asking what reasons are to still using old versions.
There's a wide range between 1.0 emulation and 1.6beta
E.g. KM154 works quite well, apart from the increasing "outdated gecko" probs. But in yet older versions those probs certainly are more, not less.
Quote
JohnHell
When K-meleon gets stuck at 100% CPU load and the only way to continue using it is close it... what is the workaround? Please, tell me, because, right now, this is the most annoying thing with 1.6b2.
Happens too rarely to me, and then mostly when I have some 30 tabs open in my oldie machine with 256MB RAM. My fault. And when 1.6beta gets stuck due to some script, I toggle windows for a second and it'S responsive again. As written before, I do have less plugins than others (no java for example), and usually all sorts of stuff blocked, incl. "DOMstorage" and "embedded objects". Hmm, when I think hard, there returns a memory about some fancy-blinky forum that used to kill KM if JS was on, but that was long before the first 1.6 version. Finally figured out it had to do with some stuff from "ajax.googleapis.com", blocked that in windows HOSTS file, and prob was gone
But the bug as you describe it exactly is rather unknown to me, sorry. Yeah it does exist, have read about it from others too in this forum.
Quote
JohnHell
The first time I hear there is no need to enable javascript to use injectJS. And, hey!, it's true.
Uffff.... ONE point gotten across, can't believe it, LOL!
No idea if it's written somewhere, I just noticed it some day. Took me just awhile to realize why it worked sometimes and other times not! Ah yes, guess I actually mentioned it myself a few times in the forum, when the subject was policy manager and the infamous caps policies. Then again, perhaps was only implying it, when posting that many default functions are blocked when using CAPS-JS-block, can't remember exactly,
Yeah, it would easier be found on macrolanguage2 page. But frankly, how often and thoroughly you study that one??
About CAPS policies:
Quote
JohnHell
But you told me. You assumed I was using it. Why?
I didn't "assume" you use it, but it wasn't completely impossible, so better mention it too. It's one of two ways to block JS in gecko, and had no idea (before digging up my 1.0x version) which one a stoneage KM had used by default. Still possible that some macro uses it, but not very likely.
Quote
JohnHell
why now is not accepted "javascript:whatever_function_to_run();" as URL?
Quote
JohnHell
But I don't toggle on-off continuously. Have a look, again, to my code. I just toggle on, inject code, let run code, toggle off.
At first, yes, but then you posted about "javascript:whatever_function_to_run();" as URL. So that sounds as injecting the last part via URLbar now instead of via injectJS. If that was just a misunderstanding, all the better.
Quote
JohnHell
Never, never, can this kill a script. Unless the toggle off is being run before wait until script finishes. This behavior is correctly made by 1.1.x, why not in 1.6b2?
It does work in 1.6b2, must be some other reason in your setup...
BTW you mentioned jit, that's also one of the things I've disabled on my oldie machine.
Quote
JohnHell
What do you have against old macro definition if they do exactly the same?
Oh nothing. Just can't help getting the impression that they don't quite exactly do the same in our 1.6b2 browsers. It works on mine. It works not on yours. "Exactly the same"?? *whistle*
Edited 1 time(s). Last edit at 08/30/2011 06:37AM by siria.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 30, 2011 07:17AM
Quote
siria
Hey, cool video!
Nop, I don't hit enter in the video. I just typed randomly to show how the mouse is hidden and then I deleted with backspace and type a real url. I was going to type www.google.com, but after the dot, when I typed g... stopped and crash, well, close, not crash, to be fair.
May be the history. It is just only ~7MB (2 months).
(The blurry is a video edition to hide my desktop and bookmarks toolbar)
Quote
siria
How come I have a hard time believing you "exactly the same"? Ah yes - because the very same code lines work fine in a "normal" macro environment and not in a "legacy emulation" environment?? That's the only difference, or do you know another? If the code itself is the same?
I don't get your differentiation between normal macro and legacy emulation, as if it wasn't built-in the same macro language supporting the same commands :-?
Are you just making fun?
Quote
siria
100% cpu load bug
In other words, a big deal to stability.
Quote
siria
Yeah, it would easier be found on macrolanguage2 page. But frankly, how often and thoroughly you study that one??
I had a look in the past, but as I don't use newer versions of KM, why bother studying it?
By the way, do you mean this page?
Quote
siria
Quote
JohnHell
why now is not accepted "javascript:whatever_function_to_run();" as URL?
Quote
JohnHell
But I don't toggle on-off continuously. Have a look, again, to my code. I just toggle on, inject code, let run code, toggle off.
At first, yes, but then you posted about "javascript:whatever_function_to_run();" as URL. So that sounds as injecting the last part via URLbar now instead of via injectJS. If that was just a misunderstanding, all the better.
In my first post my macro said "open("javascript:kmbody();");", or, in other words, I'm calling the script via URL, but is totally legal
And it was before disable javascript. So no harm.
Quote
siria
Quote
JohnHell
Never, never, can this kill a script. Unless the toggle off is being run before wait until script finishes. This behavior is correctly made by 1.1.x, why not in 1.6b2?
It does work in 1.6b2, must be some other reason in your setup...
My setup? I'll test on a new profile (I used to do), but I don't know what I could have on my setup :-?
I tested with both, enabled and disabled, JIT.
EDIT before posting: in a new profile is the same behavior, is not accepted the URL "javascript:whatever();". It is as javascript is being disabled before let the URL call to the function to work.
As I said, this doesn't happen on previous versions.
Quote
siria
Quote
JohnHell
What do you have against old macro definition if they do exactly the same?
Oh nothing. Just can't help getting the impression that they don't quite exactly do the same in our 1.6b2 browsers. It works on mine. It works not on yours. "Exactly the same"?? *whistle*
But wasn't the macro definition itself, but the call to the JS function. I did through URL instead hndlDocs. On 1.6b2, didn't work, on previous, did. If I'd use hndlDocs from the first time, it would work on 1.6b2, but that is not the story
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 30, 2011 12:48PM
Again, it works in 16b2 (for other configurations than yours).
Another little test, check if this works:
- Allow javascript
- Make sure in F2 that your setting for "Typed URLs" is to open in the CURRENT page
- Paste this line and hit enter:
javascript: function kmbody(){var body;var num = 0; var cuantos; body = document.getElementsByTagName('*'); cuantos = document.getElementsByTagName('*').length; while(num<cuantos){ body[num].style.backgroundImage = 'url(none)'; body[num].style.backgroundColor = '#858585'; body[num].style.color = '#000000'; if(body[num].href){body[num].style.backgroundColor = '#808090'} num++; } } kmbody();
Guess that's without using macrolanguage, but you say your urlbar doesnt accept it either. Mine works fine this way too.
(And try shorten your history a bit? 7MB is quite a lot for a URL collection!! But you can insist on keeping it eternally, and not even test with a smaller one, just thought you had complained how much it bugs you that 16beta is closing/crashing so often
Who knows - perhaps that history bug is also responsible for other weird crashes?? Can only tell that it happens extremely rarely to my, and my history is quite short)Edited 2 time(s). Last edit at 08/30/2011 01:07PM by siria.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 30, 2011 01:04PM
PS: Suggestion to split this thread into a youtube one and a macro versions one?
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: August 30, 2011 09:22PM
No, doesn't work.
Yes, does work. But only if you remove the enable/disable javascript trick. I was sleepy and I didn't bother to edit to say that your macro edit involved remove the enable/disable trick.
Yours works.
Edited 2 time(s). Last edit at 08/30/2011 09:54PM by JohnHell.
Re: Switching from KM1.1 to 1.6beta
Posted by:
siria
Date: August 30, 2011 11:52PM
It works?! Fine
If you think that the old js toggle has a bug, try if it works after removing &PrivacySync from the toggle. When I took a look into my ancient macros.cfg I noticed surprised that it uses "setcheck" for the priv-macros, but IIRC had tried that awhile ago and found it doesn't work for macros, then had suspected it's probably meant for ID-commands only, but not sure at all. Might very well confuse the commands and this is all nonsense. Anyway, worth a short test if you want to use that toggle for other scripts (which may contain other js commands without exception permission)
Edited 2 time(s). Last edit at 08/30/2011 11:57PM by siria.
Re: Switching from KM1.1 to 1.6beta
Posted by:
JohnHell
Date: September 08, 2011 01:25AM
Funny image: cookies everywhere.
I don't know what is worst. Have K-meleon windows locked because a cookie window message, or have them unlocked but a lot of cookie windows...
This happened the other day and was quite funny.
Note: I placed the windows just to show the mess. Usually you won't notice the creation of this bunch of windows, but I did.
Edited 2 time(s). Last edit at 09/08/2011 01:28AM by JohnHell.
