I would actually delete the three plugins by Mohammad. You can do that by using buttons like this:
<$button>
<$action-deletetiddler $tiddler="shiraz"/>
Delete "$:/plugins/kookma/shiraz"
</$button>
(the other two buttons are left up to you 
)
Save, and reload.
I suspect that the way the plugins are packed has a subtle defect. Unfortunately I can’t test this premise because the HTML5 saver is being defeated by the tiddlyhost saver. (see other post).
What I actually did was to re-import hundreds of content tiddlers (manually selected!) via the 5.2.7 upgrader, leaving out plugins and other config / stylesheet stuff, then gradually adding key config and stylesheet stuff back in.
Then I just did fresh installations of each desired plugin including the three that had been crashing on click… slowly reconfiguring to match needs. No sign of the trouble on my live 5.2.7 version, now revamped from the ground up and just a bit rough around the edges.
Not sure what the problem was, but now I need to get back to my actual tasks…
So grateful for your responsive help, @pmario @Mark_S @EricShulman and @Mohammad !
Looks to me like the issue is with this ViewTemplate: My TiddlyWiki — a non-linear personal web notebook
In spite of the “SAFE” in the title, it is still tagged with $:/tags/ViewTemplate. When the Shiraz plugin tiddler is navigated to, the wikify call in the above view template is causing the RSOD. After I removed the ViewTemplate tag, I am able to navigate to the Shiraz plugin tiddler without the RSOD.
A plugin tiddler is not meant to be wikified. But hopefully there is a way to improve the code such that it doesn’t give an RSOD. It will require more troubleshooting to find the root cause of the issue.
Thanks for tracking it down, @btheado!
Removing all custom ViewTemplates ought to have been part of my trouble-shooting, but I think my brain just ran out of juice after trying so many other things!
This custom subtitle included a word-count of the text field (something that was quick-and-handy for handling student work that always had a word count limit). I’ll be more cautious about using that subtitle customization in the future. There was actually already a note of caution about it in this thread… but it had seemed to be playing nicely for months, and apparently I lost track of it as a possible place for mischief to happen.
@Springer has some kookma plugins (e.g. Shiraz, Utility, Refnotes, Commander) which are minified using @Flibbles Uglify. The packaged plugins from kookma library all are minified using Uglify.
BUT all of them are tested with TW5.2.7 and work fine (as single or with together)
Hi @btheado
Great job, well done! It is always difficult to debug!
One question: In the test wiki, when clicking on other plugins, TW open them without problem and the mentioned view template works fine! Only when opening a kookma plugin in the test wiki the RSOD is appeared!
I think the difference is those kookma plugins are minified using @Flibbles Uglify. So, don’t you think $wikify cannot work with minified tiddler?
Further tests:
@btheado, @Flibbles
I just created a temporary wiki on Tiddlyhost: Basic Edition — temporary to track issue (tiddlyhost.com)
My conclusion: The minified plugins work fine. The view template works with minified plugin tiddlers.
I could replicate the problem clicking on any plugin tiddler with Edge. With FF it needed more time, but at the end the error did come up there too. …
So I think it’s not necessarily a problem of the minified wikitext. Minified wikitext basically is the same thing, that \whitespace trim does. So there should be no problem to wikify it.
I think the main problem with the wiki is the amount of 3rd party plugins used. There are some plugins from tobibeer, which are super old, not maintained or even tested and where developed with TW beta versions. Most of the functionality Tobias implemented can be done now with the TW core if the docs would be read.
I’m pretty sure that not all of the 42 plugin added to the wiki are really used.
LOL. Of course that’s true — see my mention of “cruft” in ;tldr above. (The ground-up rebuild has 16 beyond the core, and is 99% indistinguishable, functionally.) The trick was finding the time to be methodical in weeding out things I wasn’t actively depending on anymore. (In my defense, quite a few had been in disabled state for a long time, while I passively tested for whether I’d have regrets in removing them altogether.)
While I was busy not finding the time to keep things trim, the RSODs emerged, and were not easy to troubleshoot. So, as it were, the time found me.
I did not know this. I’ll be cautious about retaining them in this and other projects.
-Springer
Tobias had some great ideas and a talent to create well looking UI elements. But some implementations had side-effects or the filter syntax did not meet the core requirements. Several contributions have not been merged to the core. …
So he did make plugins … Most of them are great and may still work as intended. … But you have to be careful. They have not been maintained since 2017 or even earlier. … So if they contain any javascript, you really have to check if they do not overwrite core functions. …
Many of Tobias’s ideas have been implemented in a slightly different way, into the core like <$vars, which is now superseded by <$let. or decode-, encodebase64, contains, count, filter, split …
Just wanted to let you know.
Trying to follow here. So the problem is that wikifying a minified tiddler can cause problems? Or is it the attempt to count the results of the wikified, minified text?
Hi Mark,
No the wikify widget has no problem, and the minified plugins are also work as expected…
See #14 above.
Post #14 is speculative. Maybe an old plugin caused the problem. But in post #9 we’re told that the error is caused by a template. The template doesn’t seem to be invoking anything other than standard wikitext. And the errors only occurred when opening the minified plugins. So for one of the other plugins to be causing problems, it would have to be overwriting the core.
I guess I would like to know what old plugins actually cause problems with the core, so that that fact can be noted in links.tiddlywiki.com.
Yes. I was able to duplicate the issue just by dragging shiraz plugin and the view template (attached below) onto tiddlywiki.com and opening the shiraz plugin for viewing.
SAFE_ $__core_ui_ViewTemplate_subtitle.json (754 Bytes)
I think trying to wikify the plugin when it is embedded inside of json is causing the problem. I think because some of the widget tags are not closed (list widget, let widget, etc) the whole rest of the large plugin tiddler is getting included as part of the widget and it is eating a lot of memory. When processed as individual tiddlers, the unclosed tags are automatically terminated at the end of the tiddler. Needs more investigation still.
Example of unclosed widgets in Shiraz
Also note, in this case all the plugins were disabled starting early in the troubleshooting process. So for one of the old plugins to be contributing to the problem, it would have to have had significant effects despite being offline.
I appreciate the lesson about running with a leaner and better-tested set of plugins, even if – or maybe precisely because – all the other plugin tiddlers were so many red herrings.
After more troubleshooting, I’ve found I can duplicate the “RangeError: Maximum call stack size exceeded” error (that’s the error in chrome…firefox is different) by pasting this filter into the advanced search of tiddlywiki.com:
[{$:/core}splitregexp[]count[]]
In @Springer’s wiki, the wikification of $:/plugins/kookma/shiraz effectively results in the following filter being evaluated: [{$:/plugins/kookma/shiraz}splitregexp[]]. I don’t know the exact reason why that happens, but I think it is reasonable to suggest that wikification of a plugin tiddler is a bad idea and should be avoided.
@Springer, IMO, your view template should only wikify the text of the tiddler if either the type is empty or the type is text/vnd.tiddlywiki. That should reduce the chance for surprises.
This line of code is where the crash happens.
Array.prototype.push.apply(result,title.split(regExp));
In @Springer’s case, title above is the 135KB contents of the Shiraz plugin. The call to split will split on every character, so there will be 135K arguments passed to push. That is too many and it causes the crash.
Yes! A good practice, for any wordcount within a ViewTemplate, would be to surround it with a filter to ensure that it’s not trying to evaluate anything unmanageable.
I suspect that the potential for “maximum call stack size exceeded” errors is even more widespread than just the use-case @Springer encountered. For example, an RSOD can be triggered by this filter:
[[0]pad[124000]split[]]
and I’m sure there are lots of other filters that output very large lists that can result in RSOD errors.
Rather than chasing down each potential RSOD, I suggest that a generalized “throw-catch” wrapper should be added around the TWCore’s filter processing code, in order to protect against this error. I’m not sure what the “catch” handling should do in response, but at the very least it should prevent the RSOD from occurring
-e
Strangely the viewtemplate work here: (see #14)
https://temporary-minified-kookma-plugins.tiddlyhost.com/#%24%3A%2Fplugins%2Fkookma%2Fshiraz
BUT in the same wiki entring [{$:/plugins/kookma/shiraz}splitregexp[]] in $:/AdvancedSearch makes browser (Edge/Chrome 110) freezes for a while but finally shows the result!
To my conclusion the issue is not related to minification by Uglify! nor related to Shiraz, but it is related to core as described by @btheado
I will just add I have used a lot of Toiases plugins and solutions over the years. He was one of the most productive creating extensions of tiddlywiki ever. Unfortunately, he has not being active of recent years. What I tend to do now is look at how Tobias did it and consider if there are new features than can help and build new equivalents when possible.