General :
K-Meleon Web Browser Forum
I was happily using it since years instead toggle the javascript.enabled preference until I found the devil inside...
http://kmeleonbrowser.org/wiki/CommandIds#navToggleJS
Looks like when you toggle javascript this way, it also disables any disabled execution context set by pageToggleJS (and I haven't tested, but might as well happen with pageDisableJS) in other windows or tabs, so, caution, you may be thinking that JavaScript might be disabled on that tab/window, but actually is enabled after toggling navToggleJS.
I found because a page I visit now hangs with JavaScript enabled because of some JavaScript function that creates a memory leak. So I disable JS for that window/tab and then I forget about it, but when toggling in other window/tab globally with navToggleJS... boom!! and I didn't know what was going on, by it still hang if it was disabled...
So here it is the answer.
Uh oh, thanks for the warning!
And for the note in the wiki, which I found easier to grasp:
So "navToggleJS" sounds like it's acting as does Adblock-Toggle in KM1.6...? STARTING to load all the previously blocked stuff in ALL other open pages too? Silently STARTING all blocked scripts in all background tabs at once?! If yes, then YIKES...
Note to self: NEVER use this thing for ENabling JS, under no circumstances, but probably a good thing when DISabling JS...
Hmm.... trying to grasp it... perhaps means that loading a page with JS-pref off, produces exactly the same state-marker as loading *with* JS and then pageDisableJS...
That just confirms I was right to deeply distrust this 'newfangled' JS-toggle-jungle before fully grasping it. Not without first thoroughly testing myself to see what exactly happens when how and why. And then trying to memorize all possible combinations of prefs and page-toggles, but there's the prob without regular training, being stuck with old browser.
But amazed that even you got it wrong for years, whoa, that pretty much says it all!
Although I suspect that, once fully understood, the concept will seem a lot easier.
So haven't paid too much attention yet to such confusing new commands which I can't regularly use and test anyway. What still matters most for macros:
that injectJS() still keeps working as traditionally, even in KMG76+? Always functional in the PAGE where it's fired without needing any additional OnOff toggles? And especially without accidentally STARTING scripts in all other open tabs - is that true?
Or what must be done differently in 75/76...?
(NB: Would prefer to find this in Dev chapter, instead of getting lost in Wide General Ocean ;-) It's about coding, a development language, not about browser usage, and important to know for macro writers. Who have a better chance to stumble upon such stuff there, not only when searching specifically for something)
Edited 3 time(s). Last edit at 10/14/2020 10:04PM by siria.
I didn't test the latest to confirm, but I just did now a quick test with a setInterval and, yes, that is what it happens.
Background of the above:
neverending execution was the reason I requested a way to stop javascript execution when Dorian bring us 74.x as toggle off and on JS didn't stop execution since then; some remember I found a page on bugzilla and then Dorian implemented pageToggleJS.
I can't find the original post, but..., me talking about it and Dorian suggesting it:
http://kmeleonbrowser.org/forum/read.php?12,131017,131069#msg-131017
Dorian
http://kmeleonbrowser.org/forum/read.php?12,131017,131069#msg-131680
Some details about the functionality, plus this new one:
http://kmeleonbrowser.org/forum/read.php?3,133657,133686#msg-133683
To let people understand what happens:
- open a page with javascript enabled which runs something
- toggle js off in the window/tab that rendered that page with pageToggleJS
- script stops
- go to another window/tab and toggle javascript globally with navToggleJS
- script in original window/tab will continue running
This won't happen if javascript is globally toggled via javascript.enabled preference where pageToggleJS still blocks javascript on that window/tab where it was called.
No clue. I don't get exactly what do you mean.
I just though it did the same as javascript.enabled, as I wrote in the link above five years ago. But not that it reset all.
I just found because I have a macro that change the title to know when pageToggleJS is acting and that let me catch that, when navToggleJS is used, pageToggleJS for that page is reset. But wouldn't have been possible if that problematic page that loads an unsupported function didn't crash. I was with the doubt since days and I couldn't understand what the hell I was doing wrong.
Nothing trivial to find.
The problem is that isn't always clearly documented. Don't you think so?
Mostly.
And thank god JamesD for his tries, wherever is now, "up" or still on earth with us.
injectJS is always in a kind of sandbox. It always runs and recognizes what is done with other injectJS instances as long as they aren't run inside anonymous functions ( those enclosed with brackets "(function(){})();" ), except run functions that are called from external scripts and/or that need events that call them or, in other words, that really need JavaScript on.
EDIT: This is just trial/error knowledge I have found along the latest years based on all cross-interacting scripts.
In wiki?
Experienced users end on that page yes or yes if they want to know Commands IDs.
http://kmeleonbrowser.org/docs.php >>>
from "For experienced users" section http://kmeleonbrowser.org/wiki/EndUserDocs >>>
http://kmeleonbrowser.org/wiki/CommandIds
Edited 2 time(s). Last edit at 10/15/2020 12:56AM by JohnHell.
By the way, this explain an "add-on" to the default JavaScript toggle macro [in my installation] that switched back javascript off for the current window/tab/page, this is pageToggleJS.
But didn't know till now that this affected to aaaall windows/tabs
I'd need a way to populate that to all windows/tabs, as going back to toggle the javascript.enabled preference happens what I described 5 years ago, that that didn't actually stop scripts execution. Only navToggleJS does it globally, when the pages are loaded with javascript enabled.
Edited 3 time(s). Last edit at 10/15/2020 02:00AM by JohnHell.
Thanks for all the details! Will have to take a closer look just not today anymore.
I still can't quite believe that sandbox theory, at least regarding KM1.x, since in my experience injectJS really seems to toggle the GLOBAL pref on-off. Have come to that conclusion at various occasions. But seeing how KM7x handles JS now completely independant in different pages, it's well possible everything is more separated now. Then again, still wonder about the global pref... not sure from dim memory right now if it's still necessary for pageToggle-ON or not.. (should first read those old posts again)
Sounds like a PAUSE function, not a full STOP function....
The big question is:
- open a page with javascript OFF
- go to another window/tab and toggle javascript globally with navToggleJS
- script in original window/tab => ...??....
Will THIS start running or not??
Don't know about you, but I sure only need a global STOP, never a global ENABLE JS.
So... am I guessing (hoping) this right that navToggle follows the pref??
1) pref is ON
2) fire navToggleJS => sets pref OFF? (+stops everything)
3) fire togglepref, or setpref ON again (no effect for already loaded pages)
4) fire navToggle => ....??....
Hopefully AGAIN sets it OFF?
If true (?), then I'd make the JS-Button simply check the global pref first:
Looks like that JS stuff now requires 2 JS-buttons, depending on user intentions:
For global toggle and for page-toggle...
at least 2 OFF-buttons...
Then again - the JS-Page-button can never show the current state anyway??
And Global-JS-button has nothing to do anymore with already open tabs either, only for future pages?
Boah, what a mess... completely useless now as state incidators...
I already have an old macro with several red STOP-buttons, from testing stuff like window.stop() etc, in one or all pages, struggling with auto-refreshers but also not fully trusting global JS-off as KILL-function. Now planning to recycle those, with slightly different icons, for Kill-JS-page and Kill-JS-ALL...
And starting to wonder about KM7X users, how many may be aware that JS-toggle has become so dangerous now... no one ever mentioning anything about JS-probs since ever... or perhaps finding completely normal that toggling JS loads all scripts in ALL open tabs instantly...? Or... perhaps just dropping the brower when (if) noticing such probs? Or... perhaps there are now PageToggle functions added in the GUI somewhere..??
Hmm... or they don't have any PAGE-toggle anyway, and navToggleJS perhaps does not start ALL scripts only those which were already loaded before, in THAT case that would pretty much eliminate all differences to KM1.x.... if I guess it right? No idea, just a theory.
Just wondered what exactly the PrivBar button does now in KG74, and main.kmm has:
pref_ToggleJavaScript{
id(navToggleJS); &_pref_SyncButtons;
And PrivBar button in toolbars.cfg:
!JavaScript{
navToggleJS|&Privacy
=> so it's always behaving as you described above: toggling ON fires all scripts in all tabs!
Frankly, who'd need THAT? A global killer button, yes sure, but a global JS-starter? Find that completely useless, even for JS-fans. And what good are separate JS-settings for single pages, if users still find only a GLOBAL toggle?? And a lot more dangerous as before?
Ha, but suddenly starting to wonder a lot LESS why Mozilla removed the JS-pref from the GUI! (of course, first and foremost for tracking, but seeing this toggle mess, they probably were glad not having to deal with it anymore)
Of course I just meant to move the FORUM topic ;-)
Edited 1 time(s). Last edit at 10/15/2020 05:16AM by siria.
@JohnHell
>script in original window/tab will continue running
Do javascript clocks continue running in your beta?
Internally, I don't know. The test on 1.x is very simple (note, I haven't tested, but maybe after post I do). Just create a macro that injects this:
Create another macro that injects the following script:
Test with and without JavaScript enabled. If you see the alert, there you are.
On 1.x I can't confirm anything because back then I didn't use injectjs as I do now.
Only tell that I have kind of a personal API that then is called from other macros injections (at any time) and it works (with and without JS enabled) tells me what I told you before, that injectjs works in another environment. Interacts with the page, but it is always accessible.
EDIT: I CONFIRM THE injectJS BEHAVIOUR WORKS THE SAME ON1.X 1.6, to avoid confusions, with the code above and even JS disabled. As I said, it is kind of a sandbox where you can interact with other scripts already loaded with injectJS.
Yes. The deal, and what I initially reported to Dorian was that from 74.x (or was called 24.x?) toggling the pref didn't stop the scripts execution.
Then Dorian came with pageToggleJS that stops them on the current window/tab and navToggleJS that stops on all windows/tabs.
No, if you open a window/tab without JavaScript, it won't happen anything.
This is told in the linked posts I made back 5 years ago.
When you have JS initially enabled, anything would run. pageToggleJS and navToggleJS than come to the help, as switching the pref did nothing since 74.x.
When you don't, nothing happens. It is just disabled
No. I already tried to toggle, instead navToggleJS, the pref javascript.enabled. But then happens what I reported 5 years ago, that javascript.enabled doesn't stop the scripts from running. Only navToggleJS and pageToggleJS.
But, obviously, if you use the preference, despite it doesn't stop the script from running, it doesn't wake up the script of the window/tab where you loaded content with javascript enabled but used pageToggleJS to stop them. The only one that resets that window/tab is navToggleJS.
I don't think there is much people out there using them XD
I wouldn't say dangerous but originally misleading. Should have been stated, and maybe is somewhere, that pageToggleJS is reset back.
Hey, I may found myself whenever I created that "add-on" to the toggler that restored pageToggleJS, but at that time I didn't think about it happening on all windows/tabs. Probably because I'm not of using too many windows (I'm not user of tabs, actually, but it happens the same on tabbed browsing, but on tabs could even be forgiven as even they work on different contexts, they are on the same window).
The indicators works, as the button indicators are based on the preference and the preference is toggle with togglepref and navToggleJS.
Yep (bolded) that's the point!! But beyond that, that the preference on 1.x probably did the same, not toggle back when was explicitly told to a window/tab to pageToggleJS.
Maybe more to bugs..., or fill a bug, but for now I think it is fine here. Don't call bug what it is a feature XD
I'm on 75.0, no beta, but it also does the same on latest K-meleon 76 on Goanna build by roytam. And so may happen on 76RC as they are based on it.
By clocks... what do you mean? Clocks usually have a setInterval and I already told above that setInterval status, this is running, get reset despite the pageToggleJS that stopped them.
(SORRY FOR ALL EDITS too long post XD)
Edited 7 time(s). Last edit at 10/15/2020 04:06PM by JohnHell.
@JohnHell
There was a misunderstanding. I knew about navToggleJS and tried to annotate that it does not continue or start scripts. Added a script (external link) to a local page and followed order of your instructions. Clock should stay frozen until page reload.
It might be another misunderstanding. I'm not trying to say that scripts start magically
A script that does needs some firing event like onload from your example, or user interaction, just halts with pageToggleJS and navToggleJS can't make start scripts again, but restores the script functionality.
So if it there were a button in that example (append to it "<input type="button" value="restart" onclick="startTime();">
"), when navToggleJS resets pageToggleJS, it doesn't restart again, but if you click that button, the clock will start again.
All this comes that, navToggleJS resets the disabled Javascript execution of a window/tab set by pageToggleJS and, in my humble opinion, shouldn't.
And if it weren't by the case I described, a page that has some function/script that creates a memory leak on K-meleon, I wouldn't know, because it couldn't be possible that after I disabled JS for that window/tab the scripts were functional again there, so when I reloaded or followed a link from that page in the same context window/tab, boom!, again the memory leak.
Also, all I have said above, that it happens from another window/tab, it is because the customized toggle I have. If pageToggleJS was used on the current window/tab it reapplies it again. But if it weren't by it, in the current window/tab the status of javascript execution set by pageToggleJS, by disabling it, is restored after navToggleJS.
I want to clear this because I didn't even remember I had that fix for myself
Also when I talk about pageToggleJS, I mean pageDisableJS, that is what 99% of times I use it for. Rarely I re-enable it, but sometimes I do and it is better then use another macro/accel/whatever to pageEnableJS.
Edited 2 time(s). Last edit at 10/15/2020 09:48PM by JohnHell.
A little note.
anonymous, I understand your point, and this is how it worked on 1.x versions before all this and when the preference toggle of javascript.enabled switched on and off the javascript functionality on all pages.
But my point is that, now that we have pageToggleJS/pageDisableJS, there shouldn't reset the status when navToggleJS is used. Otherwise, why have a per window/tab/page toggle if then is reset? Then is better to use navToggleJS, to mimic the 1.x behaviour when toggling javascript.enabled and forget, or better, don't implement pageToggleJS/pageDisableJS (not to mention pageEnableJS), because it doesn't get sense to have them as doesn't serve to the purpose of "look, I want this window/tab/page to not have javascript functionality" because it could be reset at any time and this may lead to erroneous interpretations.
@JohnHell
Blocked navToggleJS from frames with javascript disabled and added navToggleJS to macros. It improves browsers without policy javascript.
Forgive me, but I haven't understood what you tried to say :-?
@JohnHell
Script in original window/tab stays disabled in fresh builds.
Which one so I could try myself?
The one from roytam I have here it doesn't, so, instead to test blindly, which one?
@JohnHell
Changed exe files in incompatible forks. Dorian left the sdk (link) in forum to allow rebuilding 75.x executables without much work, but it is difficult to find W2K users today. Just build yourself with VC10 using June 2015 source files and test in your own W2K SP2.
I see.
But... there is a but, me and programming is like worlds apart XD
One thing is do a couple of macros or javascript scripts and the other do C/C++ programming and fix inconsistencies, incompatibilities and add something to fix this pageToggleJS, that, to start from, I won't have a clue how to do or start from
And, did I see Python in that 7z too? Another paradigm. I don't know even Visual Basic..., or even basic..., maybe back in qbasic days I did something like compile something with guidance, but not by myself.
Anyway, thanks for the advice.
@JohnHell
No special skills needed, just opening a KMeleon.vcxproj or KMeleon.sln file. The KM 75.0 sources (link) use the SDK to compile a kmeleon.exe binary. It doesn't hurt to try and fail, because it helps to ask the right questions when Roy has more time. He knows what Windows version VC10 needs and how to build for W2K.
Still, as I said, I don't have a clue of what and how to fix.
I appreciate your efforts on encouraging me, but really, no clue. Like a fish out of water
No harm, maybe, but not a benefit for me either. I'm not in the mood of learning that now. I'm getting old.
P.S.: I'm not on 2K any more on this "new" (different) hardware, but on XP SP2, but it is a low end too. That doesn't help for certain tasks either. For example, I would be on a newer OS if it weren't by lack of RAM and HDD space.
Edited 1 time(s). Last edit at 10/18/2020 01:34AM by JohnHell.
Ohhh, how I didn't stumble upon this!!!
The hang and memory leak isn't because a javascript function, but because a CSS rule..., but don't ask me which. I already suffered this on another site but I didn't think about it...
I stumble with this when visiting the very basic blog of ssllabs.
Thanks that it is a meta link loading css stylesheet and can be blocked via "permissions.default.stylesheet" integer preference set to 2.
What CSS property is causing this... who knows!! Anyway, can't be disabled a specific property or whatever. But whatever it is, it is loaded thanks to some javascript code...
Now I can browser the problematic sites again... without proper layout..., of course :-/
But in the other hand, it might do something else, because in the problematic site that started this discovery about JS toggles I load the same CSS stylesheets through a delayed load with my own injectJS..........
Curious sites... what might be?
Ok, I found the least common denominator... async CSS load via onload changing the not set media, or usually media print, to media all.
Ha!!!
It looks like it creates an onload loop because the onload event is not removed after changing the media print, so it is, or might be, considered as a new onload event, the apply of the delayed style, and it continues endlessly.
Edited 2 time(s). Last edit at 11/04/2020 10:11PM by JohnHell.
General discussion about K-Meleon
Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 14, 2020 04:31PM
I was happily using it since years instead toggle the javascript.enabled preference until I found the devil inside...
http://kmeleonbrowser.org/wiki/CommandIds#navToggleJS
Looks like when you toggle javascript this way, it also disables any disabled execution context set by pageToggleJS (and I haven't tested, but might as well happen with pageDisableJS) in other windows or tabs, so, caution, you may be thinking that JavaScript might be disabled on that tab/window, but actually is enabled after toggling navToggleJS.
I found because a page I visit now hangs with JavaScript enabled because of some JavaScript function that creates a memory leak. So I disable JS for that window/tab and then I forget about it, but when toggling in other window/tab globally with navToggleJS... boom!! and I didn't know what was going on, by it still hang if it was disabled...
So here it is the answer.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
siria
Date: October 14, 2020 09:59PM
Quote
http://kmeleonbrowser.org/wiki/CommandIds#navToggleJS
- navToggleJS id = ID_TOGGLE_JS
- pageDisableJS id = ID_PAGE_DISABLE_JS
- pageEnableJS id = ID_PAGE_ENABLE_JS
- pageToggleJS id = ID_PAGE_TOGGLE_JS
Uh oh, thanks for the warning!
And for the note in the wiki, which I found easier to grasp:
Quote
navToggleJS / Only 75 and later.
Toggle JavaScript execution TRUE/FALSE globally in all Windows and Tabs.
Also toggles the preference "javascript.enabled" TRUE/FALSE.
Note: It is similar as just toggling the preference but also restores the page JavaScript execution status set by pageToggleJS in each independent Window or Tab were it was previously used to disable JavaScript execution in those Windows or Tabs.
So "navToggleJS" sounds like it's acting as does Adblock-Toggle in KM1.6...? STARTING to load all the previously blocked stuff in ALL other open pages too? Silently STARTING all blocked scripts in all background tabs at once?! If yes, then YIKES...
Note to self: NEVER use this thing for ENabling JS, under no circumstances, but probably a good thing when DISabling JS...
Hmm.... trying to grasp it... perhaps means that loading a page with JS-pref off, produces exactly the same state-marker as loading *with* JS and then pageDisableJS...
That just confirms I was right to deeply distrust this 'newfangled' JS-toggle-jungle before fully grasping it. Not without first thoroughly testing myself to see what exactly happens when how and why. And then trying to memorize all possible combinations of prefs and page-toggles, but there's the prob without regular training, being stuck with old browser.
But amazed that even you got it wrong for years, whoa, that pretty much says it all!
Although I suspect that, once fully understood, the concept will seem a lot easier.
So haven't paid too much attention yet to such confusing new commands which I can't regularly use and test anyway. What still matters most for macros:
that injectJS() still keeps working as traditionally, even in KMG76+? Always functional in the PAGE where it's fired without needing any additional OnOff toggles? And especially without accidentally STARTING scripts in all other open tabs - is that true?
Or what must be done differently in 75/76...?
(NB: Would prefer to find this in Dev chapter, instead of getting lost in Wide General Ocean ;-) It's about coding, a development language, not about browser usage, and important to know for macro writers. Who have a better chance to stumble upon such stuff there, not only when searching specifically for something)
Edited 3 time(s). Last edit at 10/14/2020 10:04PM by siria.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 15, 2020 12:51AM
Quote
siria
So "navToggleJS" sounds like it's acting as does Adblock-Toggle in KM1.6...? STARTING to load all the previously blocked stuff in ALL other open pages too? Silently STARTING all blocked scripts in all background tabs at once?! If yes, then YIKES...
I didn't test the latest to confirm, but I just did now a quick test with a setInterval and, yes, that is what it happens.
Background of the above:
neverending execution was the reason I requested a way to stop javascript execution when Dorian bring us 74.x as toggle off and on JS didn't stop execution since then; some remember I found a page on bugzilla and then Dorian implemented pageToggleJS.
I can't find the original post, but..., me talking about it and Dorian suggesting it:
http://kmeleonbrowser.org/forum/read.php?12,131017,131069#msg-131017
Dorian
http://kmeleonbrowser.org/forum/read.php?12,131017,131069#msg-131680
Some details about the functionality, plus this new one:
http://kmeleonbrowser.org/forum/read.php?3,133657,133686#msg-133683
To let people understand what happens:
- open a page with javascript enabled which runs something
- toggle js off in the window/tab that rendered that page with pageToggleJS
- script stops
- go to another window/tab and toggle javascript globally with navToggleJS
- script in original window/tab will continue running
This won't happen if javascript is globally toggled via javascript.enabled preference where pageToggleJS still blocks javascript on that window/tab where it was called.
Quote
siria
Hmm.... trying to grasp it... perhaps means that loading a page with JS-pref off, produces exactly the same state-marker as loading *with* JS and then pageDisableJS...
No clue. I don't get exactly what do you mean.
Quote
siria
But amazed that even you got it wrong for years, whoa, that pretty much says it all!
I just though it did the same as javascript.enabled, as I wrote in the link above five years ago. But not that it reset all.
I just found because I have a macro that change the title to know when pageToggleJS is acting and that let me catch that, when navToggleJS is used, pageToggleJS for that page is reset. But wouldn't have been possible if that problematic page that loads an unsupported function didn't crash. I was with the doubt since days and I couldn't understand what the hell I was doing wrong.
Nothing trivial to find.
The problem is that isn't always clearly documented. Don't you think so?
Mostly.
And thank god JamesD for his tries, wherever is now, "up" or still on earth with us.
Quote
siria
So haven't paid too much attention yet to such confusing new commands which I can't regularly use and test anyway. What still matters most for macros:
that injectJS() still keeps working as traditionally, even in KMG76+? Always functional in the PAGE where it's fired without needing any additional OnOff toggles? And especially without accidentally STARTING scripts in all other open tabs - is that true?
Or what must be done differently in 75/76...?
injectJS is always in a kind of sandbox. It always runs and recognizes what is done with other injectJS instances as long as they aren't run inside anonymous functions ( those enclosed with brackets "(function(){})();" ), except run functions that are called from external scripts and/or that need events that call them or, in other words, that really need JavaScript on.
EDIT: This is just trial/error knowledge I have found along the latest years based on all cross-interacting scripts.
Quote
siria
(NB: Would prefer to find this in Dev chapter, instead of getting lost in Wide General Ocean ;-) It's about coding, a development language, not about browser usage, and important to know for macro writers. Who have a better chance to stumble upon such stuff there, not only when searching specifically for something)
In wiki?
Experienced users end on that page yes or yes if they want to know Commands IDs.
http://kmeleonbrowser.org/docs.php >>>
from "For experienced users" section http://kmeleonbrowser.org/wiki/EndUserDocs >>>
http://kmeleonbrowser.org/wiki/CommandIds
Edited 2 time(s). Last edit at 10/15/2020 12:56AM by JohnHell.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 15, 2020 01:14AM
By the way, this explain an "add-on" to the default JavaScript toggle macro [in my installation] that switched back javascript off for the current window/tab/page, this is pageToggleJS.
But didn't know till now that this affected to aaaall windows/tabs
I'd need a way to populate that to all windows/tabs, as going back to toggle the javascript.enabled preference happens what I described 5 years ago, that that didn't actually stop scripts execution. Only navToggleJS does it globally, when the pages are loaded with javascript enabled.
Edited 3 time(s). Last edit at 10/15/2020 02:00AM by JohnHell.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
siria
Date: October 15, 2020 04:40AM
Thanks for all the details! Will have to take a closer look just not today anymore.
I still can't quite believe that sandbox theory, at least regarding KM1.x, since in my experience injectJS really seems to toggle the GLOBAL pref on-off. Have come to that conclusion at various occasions. But seeing how KM7x handles JS now completely independant in different pages, it's well possible everything is more separated now. Then again, still wonder about the global pref... not sure from dim memory right now if it's still necessary for pageToggle-ON or not.. (should first read those old posts again)
Quote
To let people understand what happens:
- open a page with javascript enabled which runs something
- toggle js off in the window/tab that rendered that page with pageToggleJS
- script stops
- go to another window/tab and toggle javascript globally with navToggleJS
- script in original window/tab will continue running
Sounds like a PAUSE function, not a full STOP function....
The big question is:
- open a page with javascript OFF
- go to another window/tab and toggle javascript globally with navToggleJS
- script in original window/tab => ...??....
Will THIS start running or not??
Quote
JohnHell
I'd need a way to populate that to all windows/tabs, as going back to toggle the javascript.enabled preference happens what I described 5 years ago, that that didn't actually stop scripts execution. Only navToggleJS does it globally, when the pages are loaded with javascript enabled
Don't know about you, but I sure only need a global STOP, never a global ENABLE JS.
So... am I guessing (hoping) this right that navToggle follows the pref??
1) pref is ON
2) fire navToggleJS => sets pref OFF? (+stops everything)
3) fire togglepref, or setpref ON again (no effect for already loaded pages)
4) fire navToggle => ....??....
Hopefully AGAIN sets it OFF?
If true (?), then I'd make the JS-Button simply check the global pref first:
- OFF > ON: fire setpref-ON and confirm("Start JS in current page now?")=pageEnableJS
- ON > OFF: stop either current page or all (whatever preferred)
Looks like that JS stuff now requires 2 JS-buttons, depending on user intentions:
For global toggle and for page-toggle...
at least 2 OFF-buttons...
Then again - the JS-Page-button can never show the current state anyway??
And Global-JS-button has nothing to do anymore with already open tabs either, only for future pages?
Boah, what a mess... completely useless now as state incidators...
I already have an old macro with several red STOP-buttons, from testing stuff like window.stop() etc, in one or all pages, struggling with auto-refreshers but also not fully trusting global JS-off as KILL-function. Now planning to recycle those, with slightly different icons, for Kill-JS-page and Kill-JS-ALL...
And starting to wonder about KM7X users, how many may be aware that JS-toggle has become so dangerous now... no one ever mentioning anything about JS-probs since ever... or perhaps finding completely normal that toggling JS loads all scripts in ALL open tabs instantly...? Or... perhaps just dropping the brower when (if) noticing such probs? Or... perhaps there are now PageToggle functions added in the GUI somewhere..??
Hmm... or they don't have any PAGE-toggle anyway, and navToggleJS perhaps does not start ALL scripts only those which were already loaded before, in THAT case that would pretty much eliminate all differences to KM1.x.... if I guess it right? No idea, just a theory.
Just wondered what exactly the PrivBar button does now in KG74, and main.kmm has:
pref_ToggleJavaScript{
id(navToggleJS); &_pref_SyncButtons;
And PrivBar button in toolbars.cfg:
!JavaScript{
navToggleJS|&Privacy
=> so it's always behaving as you described above: toggling ON fires all scripts in all tabs!
Frankly, who'd need THAT? A global killer button, yes sure, but a global JS-starter? Find that completely useless, even for JS-fans. And what good are separate JS-settings for single pages, if users still find only a GLOBAL toggle?? And a lot more dangerous as before?
Ha, but suddenly starting to wonder a lot LESS why Mozilla removed the JS-pref from the GUI! (of course, first and foremost for tracking, but seeing this toggle mess, they probably were glad not having to deal with it anymore)
Quote
(NB: Would prefer to find this in Dev chapter, instead of getting lost in Wide "General" Ocean ;-)
Of course I just meant to move the FORUM topic ;-)
Edited 1 time(s). Last edit at 10/15/2020 05:16AM by siria.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
anonymous
Date: October 15, 2020 02:21PM
@JohnHell
>script in original window/tab will continue running
Do javascript clocks continue running in your beta?
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 15, 2020 03:08PM
Quote
siria
Thanks for all the details! Will have to take a closer look just not today anymore.
I still can't quite believe that sandbox theory, at least regarding KM1.x, since in my experience injectJS really seems to toggle the GLOBAL pref on-off.
Internally, I don't know. The test on 1.x is very simple (note, I haven't tested, but maybe after post I do). Just create a macro that injects this:
function mytestfunction(){
alert('hello');
}
Create another macro that injects the following script:
mytestfunction();
Test with and without JavaScript enabled. If you see the alert, there you are.
On 1.x I can't confirm anything because back then I didn't use injectjs as I do now.
Only tell that I have kind of a personal API that then is called from other macros injections (at any time) and it works (with and without JS enabled) tells me what I told you before, that injectjs works in another environment. Interacts with the page, but it is always accessible.
EDIT: I CONFIRM THE injectJS BEHAVIOUR WORKS THE SAME ON
Quote
siria
Quote
To let people understand what happens:
- open a page with javascript enabled which runs something
- toggle js off in the window/tab that rendered that page with pageToggleJS
- script stops
- go to another window/tab and toggle javascript globally with navToggleJS
- script in original window/tab will continue running
Sounds like a PAUSE function, not a full STOP function....
Yes. The deal, and what I initially reported to Dorian was that from 74.x (or was called 24.x?) toggling the pref didn't stop the scripts execution.
Then Dorian came with pageToggleJS that stops them on the current window/tab and navToggleJS that stops on all windows/tabs.
Quote
siria
The big question is:
- open a page with javascript OFF
- go to another window/tab and toggle javascript globally with navToggleJS
- script in original window/tab => ...??....
Will THIS start running or not??
No, if you open a window/tab without JavaScript, it won't happen anything.
This is told in the linked posts I made back 5 years ago.
When you have JS initially enabled, anything would run. pageToggleJS and navToggleJS than come to the help, as switching the pref did nothing since 74.x.
When you don't, nothing happens. It is just disabled
Quote
siria
Quote
JohnHell
I'd need a way to populate that to all windows/tabs, as going back to toggle the javascript.enabled preference happens what I described 5 years ago, that that didn't actually stop scripts execution. Only navToggleJS does it globally, when the pages are loaded with javascript enabled
Don't know about you, but I sure only need a global STOP, never a global ENABLE JS.
So... am I guessing (hoping) this right that navToggle follows the pref??
1) pref is ON
2) fire navToggleJS => sets pref OFF? (+stops everything)
3) fire togglepref, or setpref ON again (no effect for already loaded pages)
4) fire navToggle => ....??....
Hopefully AGAIN sets it OFF?
If true (?), then I'd make the JS-Button simply check the global pref first:
- OFF > ON: fire setpref-ON and confirm("Start JS in current page now?")=pageEnableJS
- ON > OFF: stop either current page or all (whatever preferred)
Looks like that JS stuff now requires 2 JS-buttons, depending on user intentions:
For global toggle and for page-toggle...
at least 2 OFF-buttons...
Then again - the JS-Page-button can never show the current state anyway??
And Global-JS-button has nothing to do anymore with already open tabs either, only for future pages?
Boah, what a mess... completely useless now as state incidators...
No. I already tried to toggle, instead navToggleJS, the pref javascript.enabled. But then happens what I reported 5 years ago, that javascript.enabled doesn't stop the scripts from running. Only navToggleJS and pageToggleJS.
But, obviously, if you use the preference, despite it doesn't stop the script from running, it doesn't wake up the script of the window/tab where you loaded content with javascript enabled but used pageToggleJS to stop them. The only one that resets that window/tab is navToggleJS.
Quote
siria
And starting to wonder about KM7X users, how many may be aware that JS-toggle has become so dangerous now... no one ever mentioning anything about JS-probs since ever... or perhaps finding completely normal that toggling JS loads all scripts in ALL open tabs instantly...? Or... perhaps just dropping the brower when (if) noticing such probs? Or... perhaps there are now PageToggle functions added in the GUI somewhere..??
Hmm... or they don't have any PAGE-toggle anyway, and navToggleJS perhaps does not start ALL scripts only those which were already loaded before, in THAT case that would pretty much eliminate all differences to KM1.x.... if I guess it right? No idea, just a theory.
I don't think there is much people out there using them XD
I wouldn't say dangerous but originally misleading. Should have been stated, and maybe is somewhere, that pageToggleJS is reset back.
Hey, I may found myself whenever I created that "add-on" to the toggler that restored pageToggleJS, but at that time I didn't think about it happening on all windows/tabs. Probably because I'm not of using too many windows (I'm not user of tabs, actually, but it happens the same on tabbed browsing, but on tabs could even be forgiven as even they work on different contexts, they are on the same window).
Quote
siria
Just wondered what exactly the PrivBar button does now in KG74, and main.kmm has:
pref_ToggleJavaScript{
id(navToggleJS); &_pref_SyncButtons;
And PrivBar button in toolbars.cfg:
!JavaScript{
navToggleJS|&Privacy
The indicators works, as the button indicators are based on the preference and the preference is toggle with togglepref and navToggleJS.
Quote
siria
=> so it's always behaving as you described above: toggling ON fires all scripts in all tabs!
Frankly, who'd need THAT? A global killer button, yes sure, but a global JS-starter? Find that completely useless, even for JS-fans. And what good are separate JS-settings for single pages, if users still find only a GLOBAL toggle?? And a lot more dangerous as before?
Yep (bolded) that's the point!! But beyond that, that the preference on 1.x probably did the same, not toggle back when was explicitly told to a window/tab to pageToggleJS.
Quote
siria
Quote
(NB: Would prefer to find this in Dev chapter, instead of getting lost in Wide "General" Ocean ;-)
Of course I just meant to move the FORUM topic ;-)
Maybe more to bugs..., or fill a bug, but for now I think it is fine here. Don't call bug what it is a feature XD
Quote
anonymous
@JohnHell
>script in original window/tab will continue running
Do javascript clocks continue running in your beta?
I'm on 75.0, no beta, but it also does the same on latest K-meleon 76 on Goanna build by roytam. And so may happen on 76RC as they are based on it.
By clocks... what do you mean? Clocks usually have a setInterval and I already told above that setInterval status, this is running, get reset despite the pageToggleJS that stopped them.
(SORRY FOR ALL EDITS too long post XD)
Edited 7 time(s). Last edit at 10/15/2020 04:06PM by JohnHell.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
anonymous
Date: October 15, 2020 05:07PM
@JohnHell
There was a misunderstanding. I knew about navToggleJS and tried to annotate that it does not continue or start scripts. Added a script (external link) to a local page and followed order of your instructions. Clock should stay frozen until page reload.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 15, 2020 09:44PM
Quote
anonymous
@JohnHell
There was a misunderstanding. I knew about navToggleJS and tried to annotate that it does not continue or start scripts. Added a script (external link) to a local page and followed order of your instructions. Clock should stay frozen until page reload.
It might be another misunderstanding. I'm not trying to say that scripts start magically
A script that does needs some firing event like onload from your example, or user interaction, just halts with pageToggleJS and navToggleJS can't make start scripts again, but restores the script functionality.
So if it there were a button in that example (append to it "<input type="button" value="restart" onclick="startTime();">
"), when navToggleJS resets pageToggleJS, it doesn't restart again, but if you click that button, the clock will start again.
All this comes that, navToggleJS resets the disabled Javascript execution of a window/tab set by pageToggleJS and, in my humble opinion, shouldn't.
And if it weren't by the case I described, a page that has some function/script that creates a memory leak on K-meleon, I wouldn't know, because it couldn't be possible that after I disabled JS for that window/tab the scripts were functional again there, so when I reloaded or followed a link from that page in the same context window/tab, boom!, again the memory leak.
Also, all I have said above, that it happens from another window/tab, it is because the customized toggle I have. If pageToggleJS was used on the current window/tab it reapplies it again. But if it weren't by it, in the current window/tab the status of javascript execution set by pageToggleJS, by disabling it, is restored after navToggleJS.
I want to clear this because I didn't even remember I had that fix for myself
Also when I talk about pageToggleJS, I mean pageDisableJS, that is what 99% of times I use it for. Rarely I re-enable it, but sometimes I do and it is better then use another macro/accel/whatever to pageEnableJS.
Edited 2 time(s). Last edit at 10/15/2020 09:48PM by JohnHell.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 16, 2020 03:13PM
A little note.
anonymous, I understand your point, and this is how it worked on 1.x versions before all this and when the preference toggle of javascript.enabled switched on and off the javascript functionality on all pages.
But my point is that, now that we have pageToggleJS/pageDisableJS, there shouldn't reset the status when navToggleJS is used. Otherwise, why have a per window/tab/page toggle if then is reset? Then is better to use navToggleJS, to mimic the 1.x behaviour when toggling javascript.enabled and forget, or better, don't implement pageToggleJS/pageDisableJS (not to mention pageEnableJS), because it doesn't get sense to have them as doesn't serve to the purpose of "look, I want this window/tab/page to not have javascript functionality" because it could be reset at any time and this may lead to erroneous interpretations.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
anonymous
Date: October 16, 2020 09:19PM
@JohnHell
Blocked navToggleJS from frames with javascript disabled and added navToggleJS to macros. It improves browsers without policy javascript.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 17, 2020 01:08AM
Forgive me, but I haven't understood what you tried to say :-?
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
anonymous
Date: October 17, 2020 03:34PM
@JohnHell
Script in original window/tab stays disabled in fresh builds.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 17, 2020 04:59PM
Which one so I could try myself?
The one from roytam I have here it doesn't, so, instead to test blindly, which one?
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
anonymous
Date: October 17, 2020 05:58PM
@JohnHell
Changed exe files in incompatible forks. Dorian left the sdk (link) in forum to allow rebuilding 75.x executables without much work, but it is difficult to find W2K users today. Just build yourself with VC10 using June 2015 source files and test in your own W2K SP2.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 17, 2020 10:21PM
I see.
But... there is a but, me and programming is like worlds apart XD
One thing is do a couple of macros or javascript scripts and the other do C/C++ programming and fix inconsistencies, incompatibilities and add something to fix this pageToggleJS, that, to start from, I won't have a clue how to do or start from
And, did I see Python in that 7z too? Another paradigm. I don't know even Visual Basic..., or even basic..., maybe back in qbasic days I did something like compile something with guidance, but not by myself.
Anyway, thanks for the advice.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
anonymous
Date: October 17, 2020 11:47PM
@JohnHell
No special skills needed, just opening a KMeleon.vcxproj or KMeleon.sln file. The KM 75.0 sources (link) use the SDK to compile a kmeleon.exe binary. It doesn't hurt to try and fail, because it helps to ask the right questions when Roy has more time. He knows what Windows version VC10 needs and how to build for W2K.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: October 18, 2020 01:32AM
Still, as I said, I don't have a clue of what and how to fix.
I appreciate your efforts on encouraging me, but really, no clue. Like a fish out of water
No harm, maybe, but not a benefit for me either. I'm not in the mood of learning that now. I'm getting old.
P.S.: I'm not on 2K any more on this "new" (different) hardware, but on XP SP2, but it is a low end too. That doesn't help for certain tasks either. For example, I would be on a newer OS if it weren't by lack of RAM and HDD space.
Edited 1 time(s). Last edit at 10/18/2020 01:34AM by JohnHell.
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: November 04, 2020 09:26PM
Ohhh, how I didn't stumble upon this!!!
The hang and memory leak isn't because a javascript function, but because a CSS rule..., but don't ask me which. I already suffered this on another site but I didn't think about it...
I stumble with this when visiting the very basic blog of ssllabs.
Thanks that it is a meta link loading css stylesheet and can be blocked via "permissions.default.stylesheet" integer preference set to 2.
What CSS property is causing this... who knows!! Anyway, can't be disabled a specific property or whatever. But whatever it is, it is loaded thanks to some javascript code...
Now I can browser the problematic sites again... without proper layout..., of course :-/
But in the other hand, it might do something else, because in the problematic site that started this discovery about JS toggles I load the same CSS stylesheets through a delayed load with my own injectJS..........
Curious sites... what might be?
Re: Macrolanguage navToggleJS command id, learning the hard way
Posted by:
JohnHell
Date: November 04, 2020 09:56PM
Ok, I found the least common denominator... async CSS load via onload changing the not set media, or usually media print, to media all.
Ha!!!
It looks like it creates an onload loop because the onload event is not removed after changing the media print, so it is, or might be, considered as a new onload event, the apply of the delayed style, and it continues endlessly.
Edited 2 time(s). Last edit at 11/04/2020 10:11PM by JohnHell.
English