Sandbox the preview window?

Developers
#1

When designing complex TiddlyWiki script it is useful to have the preview output window open to see the result.

There are a small subset of things that the editor can do that will cause loops and even crashes. Knowing when to stop the preview so this does not hapen is subtle and you need to be ever viligent to avoid this.

I am wondering if some of our core developers, or Javascript gurues think of a way to “sand box” the preview window in a way that it times out or displayes an error message if a problem seems to exist as it attempts to render the preview.

  • This would allow us to edit and preview the output without fear of either loosing our latest changes or the wiki itself, and the hastle of recovering.
  • One could apply this to rendering all tiddlers but just focusing on the preview would mean any performace hit may be acceptable. This could be set to only happen on the current tiddler when using $:/config/ShowEditPreview/PerTiddler = yes

I am confident this is possible but it may be hard to find how to do it, but it could be a powerful feature for anyone writting javascript code, not just in tiddlywiki.

Post script:

  • Perhaps the first render after saving a tiddler could allso use the sand box?
1 Like
#2

Innerwiki plugin?          

#3
  • Unlikely as I want to preview only the tiddler I am editing, and benefit from the current values and data in the current wiki.
  • But possibly based in the methods in innerwiki.
  • I belive there is an iframe in the editor, some how use this for the preview?
#5

In a recent conversation Nice Dice this timeout was mentioned TiddlyTools for TW5 v5.3.1 — Small Tools for Big Ideas!™ and illustrates a possible approach to apply to the preview window.

#6

It’s an interesting idea @TW_Tones. I think that it could be achieved with the innerwiki plugin. The performance might not be great because it would have to load the inner wiki with a complete copy of the tiddlers from the parent wiki.

1 Like
#7

Thanks @jeremyruston

I was wondering if there was a way to move the previews render into some type of subprocess, iframe etc… with a time out, but then I don’t have advanced javascript code skills. Or perhaps some of the performance tool methods could terminate it after even more than 30 seconds of processing in the same “process”, but I expect the browser does not have this level of control.

  • If inner wiki is the only way it would be worth trying however we would be unlikely to use it if it slows down previews performance too much (even when there is no loop in progress).
  • I wonder if a parallel render process could be started that has a timeout test on it?
  • Or perhaps show the preview in a separate window that can be terminated.

Sometimes it takes only a misplaced single character in the editor with the preview open to cause multiple timeouts or a wiki failure.

Just some thoughts

#8

That is exactly what the innerwiki plugin does. It is precisely tailor made to solve the problem you quote in the OP.

Your OP correctly identifies an embedded iframe as the sandbox mechanism. The innerwiki plugin is the simplest, cleanest possible implementation of an embedded wiki in an iframe.

I understand the problem, and your proposed solution, and am confirming that the innerwiki plugin provides the basic functionality you have identified.

2 Likes
#9

Just a related thought;

It would be great if the preview output and possibly other previews could be placed in a sandbox, but it may be somewhat practical if there were a widget in which we wrap a section of TiddlyWiki script to place it in a sandbox of its own.

  • This $sandbox widget could be used during development, wrapping the text field (or part there of), and would effect both the preview and the tiddler view mode equaly, perhaps with an indicator it was in a sand box.
  • If there is a run away process inside, the sand box just displays an “internal error” and any information that can be gleaned.
  • In the future we may be able to add other features to the sandbox widget that does a balanced open/close tag check, other syntax checks etc… but only is applied when tiddlywiki script is inside the sandbox (widget)
  • Have dodgy code?, then wrap it in the sandbox or perhaps debug widget.
#10

Further to this topic, which has not yet progressed I am currently waiting for a very long process to complete, simply because I had the preview open for output and possibly misspelt my filter [all[shdows+tiddlers]. This is such a pain.

This is most common on the list widget from experience, and where it occurs in other uses of filter, the list widget is possible in use here to.

Perhaps we could modify the list widget to have a time out that if it runs too long, or too many itterations to generate an option to proceed or exit. Ideally this can be toggled on/off and the timeout or number set.

The error occurring for me now is very disruptive;

  • I have to wait forever
  • I cant
    • reopen the wiki in another tab
    • copy my last edits from the window in front of me.
    • reload the tab (and loose changes)
  • I can only
    • Close the tab, but not reopen it.
    • Close the browser, loosing changes since last save
    • Close the tab but not reopen