Recursive error in template tiddler not getting caught in 5.3.0

Developers
#1

Hello,

I have the following construct in some of my pre-5.3.0 wikis as part of a template tiddler:

<$reveal type="nomatch" state="!!text" text="">
...
<$transclude mode=block/>
...
</$reveal>

I feed a list of tiddlers to it and it does not show anything if that tiddler is blank. When I view that template tiddler in pre-5.3.0 to edit it, the typical error that it is recursive is displayed but I can edit the tiddler as normal.

As of 5.3.0, the template tiddler does what it should when used from another tiddler but the Chrome (on Windows 10) browser locks up or gives me the “Oh snap” error when I try to view the template tiddler to edit it.

Sorry I did not detect this in the 5.3.0 beta shake-down as my wiki works just fine in 5.3.0 so the problem was hidden. It is only a problem when I open the template tiddler to make some changes.

I tried this same code sample in Firefox (on Linux) and it gave the proper recursion error the same as pre-5.3.0.

Thanks,
/Mike

Addendum:
Works fine on
Chrome on Linux:

Google Chrome 114.0.5735.198 (Official Build) (64-bit)
Revision c3029382d11c5f499e4fc317353a43d411a5ce1c-refs/branch-heads/5735@{#1394}
OS Linux
JavaScript V8 11.4.183.25

Firefox v. 115.0 (64-bit) on Fedora Linux 38

Does not work (even on plain tiddlywiki.com):
Chrome v 114.0.5735.199 (Official Build) (32 bit) (cohort: Stable) on Windows 10 Enterprise

#2

Sounds serious, a few notes to get this started;

  • How are you using the above template?, as list item template or using a tag like $:/tags/ViewTemplate
  • If you want to edit something without first viewing it you can edit $:/core/ui/ListItemTemplate to look like this,
    • <div class="tc-menu-list-item">{{||$:/core/ui/Buttons/edit}} <$link /></div>
    • Then all the advanced search tabs have a edit tiddler direct button.
  • I expect this needs to be solved but also concider a workaround, at least to see if that solves the problem eg; use a list rather than reveal to conditionaly display the transclusion
    • [all[current]!has[text]]
#3

Since it is a template, you can add the code-body field and set the value to yes. So the template will not be rendered if you open it for editing. The rendering should still work fine

#4

Thanks for the workaround suggestions. As mentioned, the template works fine as-is. I was thinking about changing the <$reveal> constructs into <$list> ones anyways to make for cleaner html output (<$reveal> tends to leave empty-<div>-cruft around) so there are likely tons of different ways of avoiding this issue.

I think pmario’s code-body suggestion will do the trick to allow me to open the template to make future changes … I can think of quite a few ways of making the change without viewing the tiddler directly.

Thanks for your help.
/Mike

#5

We use the code-body mechanism for some core UI templates too to make them easy to read and edit.

There has been a discussion at GitHub 2 weeks ago: [BUG] $:/core/ui/PageTemplate/story Caught in a dead loop on entry · Issue #7579 · Jermolene/TiddlyWiki5 · GitHub where Jeremy said:

[. . .] the recursion protection is working as intended here: a fixed number of recursive transclusions are allowed, but once they reach that number further transclusions are disabled. Prior to v5.3.0 a different recursion detection mechanism was used, that worked by preventing repeated nested transclusions with the same parameters. The advantage of the old approach was that it would cut off recursions like the OP immediately. The trouble was that the old mechanism couldn’t detect many types of infinite recursion. The new mechanism just relies of detecting excessive stack growth, and is robust.

It is possible that we should reduce the maximum allowed depth, which is currently set to 1000:

@jeremyruston … May be we set that limit a bit lower. As mentioned in the OP it seems to depend on internal browser settings too. So may be we try 342 instead?

1 Like
#6

Thanks @mwiktowy @pmario

We need some experimentation to determine the impact of reducing the limit. When rendering the tw5.com edition, the maximum widget tree depth that is reached is 56. One could imagine more complex layouts requiring even more depth.

What was the reason for suggesting 342?

#7

Sorry. Just a random number. 42 is “the” magic number and we need a several hundred more :slight_smile:

#8

Hi @mwiktowy do you mean that there is a problem with viewing tiddlywiki.com on 32-bit Chrome for Windows? What steps are needed to see the error?

#9

Hi @jeremyruston

To be clear, in an attempt to make sure that the problem wasn’t some custom thing on one of my wikis, I loaded up tiddlywiki.com, added the above reveal/transclude code to a new tiddler and that browser tab froze/crashed as soon as I left edit mode.

I haven’t come across instances of core tiddlers causing this issue but I have not looked specifically.

Thanks,
/Mike

#10

Thanks @mwiktowy.

I suspect that reducing the maximum widget tree depth won’t properly resolve the original problem because even with a reduced maximum there will still be enough repetitions of the content to cause problems.

But, it would be good to test this hypothesis, so I’ve prepared a special build of the current prerelease which has the maximum widget tree depth set to 150:

https://reduced-widget-tree-max-depth.tiddlyhost.com/#%24%3A%2Fcore%2Fmodules%2Fwidgets%2Fwidget.js

Please could you give it a try? Many thanks.

#11

Hi @jeremyruston

That version of the widget.js prevents the wiki crash on the platform. For reference, I tried a bunch of values (saving and reloading in between), in an empty TW, the MAX_WIDGET_TREE_DEPTH of 676 is the last good value … 677 crashes. The specific error code is “STATUS_STACK_OVERFLOW”.

There was a second change in there:

+⇥	⇥	⇥	if(domNode.parentNode) {↩︎
⇥	⇥	⇥	⇥	domNode.parentNode.removeChild(domNode);↩︎
+⇥	⇥	⇥	}↩︎

I am not sure how that factors in.

/Mike

#12

Great, thank you @mwiktowy. On that basis perhaps I’ll update the default to 500.

That’s another of the changes between v5.3.0 and the prerelease. See Comparing v5.3.0...master · Jermolene/TiddlyWiki5 · GitHub for a complete list of the changes

1 Like
#13

Hi @jeremyruston,

While those limits work on an empty Tiddlywiki with that simple code example above, on further testing with my more complex templates, even the 150 limit is not sufficient. Chrome just locks up until it crashes with an “Error Code: Out of memory”.

Is there an issue with using both styles of recursion detection (pre-5.3.0 method that works quickly but maybe doesn’t cover all cases and the 5.3.0 method as a backup to catch the rest) in a belt-and-suspenders philosophy or does the old style interfere with the new functionality?

Thanks,
/Mike

#14

That may turn out to be necessary but I’d prefer to avoid doing it if we can because the pre-5.3.0 method was subject to false positives (ie situations where a recursion error would be signalled incorrectly) as well as the false negatives I mentioned earlier.