[BUG] Internal JavaScript Error on giving invalid "tag" attribute values for certain widgets #8166
Comments
|
Just figured out that the simplest form to reproduce the issue is: The reason why the transclude widget and macro call widget, but not the macrocall wikitext syntax ( My suspicion is that this can happen with any widget that accepts |
|
Forget my comment at Talk. It's a different issue. Sorry. I did not look good enough |
|
The droppable widget has a tag-parameter, which is used to create DIVs or SPANs .. The "tag" parameter of the transclude-widget is parsed as an input for the draggable-widget. The draggable now thinks we want to create a I'm not sure if there is an easy solution to this one -- We probably should fall back to create a SPAN or DIV if the tag-attribute is invalid. There is no validity check at the moment, since the browser throws an exception, which you can see |
|
Yep, it seems anything that allows you to override the HTML element through a "tag" attribute has the issue. For example, even And yes, I would think falling back would be reasonable if the specified HTML tag is invalid, or alternatively, rendering an error message similar to "Undefined widget: xxx" or "Filter error: xyz" (rather than leaving an uncaught JS error). |
bluepenguindeveloper
changed the title
|
Also edited the bug to be more to the point, now that we know what the issue really is (while leaving the original in strikethrough) |
|
Thanks @bluepenguindeveloper – this should be fairly straightforward to fix, and might make a good first PR for somebody. |
This feels like an invitation, so I'm starting to read the developer docs and CLA just in case the time has come for me to contribute. But I'm curious about one thing: would I be required to add my real name to the public list of contributors, or would it be possible for me to remain pseudonymous (at least publicly)? I see a few entries with just the GitHub username but it looks like the vast majority include a real full name. |
|
@bluepenguindeveloper ... There are several users signing CLA with their alias. So it should be good for you too. |
Describe the bug
The code<$droppable <$macrocall $name="tag" tag="$:/tags/Global"/>results in the Internal JavaScript ErrorUncaught InvalidCharacterError: Failed to execute 'createElement' on 'Document': The tag name provided ('$:/tags/Global') is not a valid name.Edit: Certain widgets that support overriding the default HTML tag for the widget cause uncaught JS errors when given an invalid value for the "tag" attribute. For example,
<$edit-text tag="$"/>or<$droppable tag="$"/>.Expected behavior
JS error is caught and a syntax error should be displayed
To Reproduce
Paste<$droppable <$macrocall $name="tag" tag="$:/tags/Global"/>into the editorEdit: simply paste
<$droppable tag="$"/>Screenshots
TiddlyWiki Configuration
Desktop (please complete the following information):
Additional context
Edit: The below behavior was part of how this was discovered and the cause determined, but now that the example of
<$edit-text tag="$"/>is known, the below examples are no longer needed to understand the issue.<$transclude>widget (<$droppable <$transclude $variable="tag" tag="$:/tags/Global"/>)<$droppable <<tag "$:/tags/Global">>)<$droppable <$macrocall $name="tag" tag="Macros"/>); it appears the dollar sign$in the tag name is partially the cause of the issue.Note: The original intention was to complete the full
<$droppable>widget, adding it around an existing<$macrocall>widget. But when typing<$droppable>one character at a time, you get to<$droppableand the error occurs before you can finish off with the>. (The point being that this isn't merely what you can find by experimenting with invalid syntax in attempt to break TW; it first happened to me in the natural course of trying to write valid syntax with the preview pane open.)The text was updated successfully, but these errors were encountered: