Incomplete droppable widget around transclude widget of tag macro causes JS error

Developers
#1

In an empty wiki or in the documentation, open a new tiddler, turn on the side-by-side preview, and add the following:

<$transclude $variable="tag" tag="$:/tags/Global"/>

Then add a <$droppable> widget around it by going one line above the <$transclude> widget and typing it out. As soon as the word “droppable” (that is, <$droppable) is complete, we get a JS error. (You can also just paste <$droppable <$transclude $variable="tag" tag="$:/tags/Global"/> into the editor and open the preview pane.)

image
image1118×535 31.3 KB

Experimentation has shown that the error does not occur if you use <<tag "$:/tags/Global"> instead of the <$transclude> widget, and it also doesn’t occur if a tag is used that only contains alphabetic characters (such as “Macros” if done in the documentation instead of an empty wiki).

This happens in chromium-based browsers (at least Brave and TiddlyDesktop).

Additionally, when I did this in an already-existing tiddler TiddlyDesktop and, when the error showed up, clicked the in-TiddlyWiki refresh button - that tiddler showed up as missing after the refresh. (However, when I closed TiddlyDesktop and reopened the same wiki, the tiddler was back.) Not sure what this means, other than that the in-TiddlyWiki refresh button (at least in TiddlyDesktop) does not simply reload from the wiki file, but from some other state, and that state had gotten messed up by the JS error. (See this comment for the explanation.)

I will browse GitHub issues to see if I can find anything similar, but if I can’t find anything there and nobody here says it’s a known issue, then I’ll submit a bug report. (Edit: opened [BUG] Internal JavaScript Error on incomplete DroppableWidget around tag macrocall · Issue #8166 · Jermolene/TiddlyWiki5 · GitHub)

#2

This is invalid syntax, and not surprising it is in error. Try;

<$droppable>
<$transclude $variable="tag" tag="$:/tags/Global"/>
</$droppable>

or a version of this

#3

I was literally trying “a version of this.” I first added the transclude widget, and then I began typing the droppable widget around it. To type <$droppable> I first have to type < and then $ and then d and so on. But before I could close off with >, the error occurred. So unless you’re suggesting I don’t use the tiddler editor to type, and only paste completely formed code into it, this is not a solution.

Obviously. And it’s inevitable when typing code to momentarily create invalid syntax.

It is surprising that it is a Javascript error requiring me to reload the wiki.

#4

There are a number of cases where partial code causes errors. I have long argued for some kind of sandboxing of the preview window, however until then we can only close the preview window to stop rendering error states.

  • This is particularly the case with transclusion.
1 Like
#5

Haha yep. Although (to my knowledge) most of the issues with transclusion are due to uncaught infinite loops or recursion. This one’s different, though it happens to also involve a transclude widget.

I’ll test with a macrocall widget before submitting the GitHub bug (also still looking to see if a similar bug has already been submitted). Edit: it also occurs using <$macrocall> instead of transclude.

#6

Opened [BUG] Internal JavaScript Error on incomplete DroppableWidget around tag macrocall · Issue #8166 · Jermolene/TiddlyWiki5 · GitHub

#7

One thought is to set the preview to Raw HTML, needs the internals plugin. This should stop the error occurring and perhaps indicate the malformed rendering that is giving rise to the error.

1 Like
#8

Correction: This seems to be entirely unrelated to the JS error, and probably expected behavior. If I simply open any draft tiddler and then click the in-TW refresh button, it shows as missing. My guess is it’s because I have the default tiddlers (on opening) set to [list[$:/StoryList]] to automatically reopen where I left off. I think the it’s keeping this state. So when I edit a tiddler, the draft is added to the story list, but when I refresh without saving the wiki first, the wiki doesn’t have the draft saved in it. So if this kind of refresh doesn’t reset the story list to the last save, then I think it’s just got the draft in the story list, but the draft doesn’t exist because it wasn’t part of the saved wiki.

#9

Another update (this one to the original bug): I’ve further narrowed it down.

The reason seems to be that in the transclusion or macrocall widget, we have tag=... with $ in the tag name, and it is considering that as an attribute to the droppable widget.

To simplify the reproduction: <$droppable tag="$" /> (No syntax error here, just the use of $ in the tag attribute of a droppable widget.)

#10

Depending on settings, a tiddlername can appear in the browser address bar as the last navigated tiddler, and reload tries to open that tiddler, and whilst it does not exist it opens the missing tiddler.

It great you are experimenting and observing @bluepenguindeveloper some of what you will see will be side effects of other larger and more involved parts of tiddlywiki and browser behaviour. Keep them in mind because one day you may find a way to make use of them, I have :nerd_face:

  • TiddlyWiki has had a fairly long and distinguished career and many contributors and discussions. What a new user may find curious or unnecessary is i fact intentionally used by someone.

Always fee free to ask in this open and helpful community and we appreciate views from different levels of experience and perspective.

1 Like
#11

Yes so using the internals plugin, on tiddlywiki, we can see the resulting html

<$droppable tag="$" /> becomes <p><$ class=" tc-droppable"></$></p>

You can sometimes ignore such popup errors and continue, but save and reload is advised, in critical situations.

Remember with the preview open for output, it’s is like you are running an “interpreter” that is always evaluating your code as you type, even when incomplete or illegal. This is in part why the draft mechanism hides the finished tiddler and displays the editor, and does not re-render it until you save (or open the preview).

As an experienced user, I have learned to “write defensively”, hide preview unless I have a specific reason, and I often write code to see intermediate results, which allows me to test my assumptions as I go, I often find code already in TiddlyWiki and copy and clone then make changes, or reference code snipits I have off line, as would a programmer in most languages. This reduces the occurrence of such half coded errors.

I Think it is more likely the address line, as the story list is not saved by default.

  • This behaviour all changes again if you have changed the save filter and or installed the local storage plugin, but that is for your future exploration.

In summary

Don’t be too concerned about red error messages that occur attempting to render half written code.

1 Like
#14

It seems to be a parser problem. More investigation needed.

#15

I think the parser is actually fine; it’s parsing the tag=... part as an attribute of the droppable widget since that was not closed. This accounts for the differences in the behavior when using <<tag "$:/tags/Global">> instead of the transclude or macrocall widget, as explained here. If you get rid of all the transclude widget stuff and just keep the attribute at issue, even <$droppable tag="$" /> causes the same error.

Maybe I should update the GitHub issue as “Widgets that support overriding the generated HTML tag with the “tag” attribute cause JS error if invalid characters such as ‘$’ are given in the “tag” attribute.”

Edit: I see on GitHub you have already observed the same.

#16

I have edited the GitHub issue to more accurately state the bug.

#17

This is good to keep in mind. Of course, ideally, the “interpreter” should simply output an error message rather than crash, but since in TW that isn’t always the case:

This is very good advice.

Edit: Maybe it would be helpful to have a preview pane setting to not automatically refresh, and allow you to refresh the preview pane with the click of a button instead. This might also be easier to implement than a full sandbox, while not being unlike various online tools (for other programming languages) that allow you to edit code and then click a “run” button to see the new output after your changes.

#18

I tested this and it did not crash, only gave the red message and suggested a reload. It continued to operate.

#19

This particular case doesn’t crash, but some other cases (in particular, the transclusion cases, as you noted elsewhere) do, making your advice about only opening the preview pane when you want to check intermediate results (of valid code) very good advice.

But for the most part, the JS error is equivalent to a crash in my book, since you have to reload the wiki to be safe. In a way, it’s even worse, because it doesn’t actually force you to restart, so nothing prevents you from saving a corrupted wiki if whatever went wrong did indeed result in data loss (the possibility of which is why it suggests a refresh in the first place, if I’m not wrong). Though admittedly, unlike a crash, you have the opportunity to copy your text to a text file outside the wiki while you restart TW, so that you don’t lose the progress on whatever you were working on that caused the error.

1 Like
#20

It’s worth noting that from the core team perspective, any wikitext construction that produces the “red screen of embarrassment” is classed as a bug, and we would aim to fix it.

3 Likes