More friendly error prompt interface

Developers
#1

As we all know, browser extensions are not friendly to tiddlywiki and often prompt error red pop-ups. However, some error prompts are irrelevant to tiddlywiki, and tiddlywiki can still work normally.

image

If the same error is triggered multiple times at the same time, tiddlywiki will pop up multiple error interfaces. These interfaces have no error counts. Even if the close button is clicked, it will give people the illusion that the click is invalid, because there is still an identical error prompt interface below. .

Maybe we can imitate gitea’s approach and merge duplicate error reporting interfaces, or add an error prompt UI.

It is too direct to directly prompt the error interface in the center of the user’s screen. Maybe we can fix it in a corner of the window and click to view the specific expletives. @jeremyruston

1 Like
#2

Or we can use a certain status to prompt whether an error has occurred on the current page. Just like tiddlywiki’s saved state.

#3

My temporary solution is to hide this error pop-up window through styles

<% if [{$:/info/url/protocol}match[https:]] %>
.tc-error-form {
  display: none;
}
<% endif  %>
1 Like
#4

This does need repair, even if it had clear all on the red popup.

  • Occasionally, and more so of late this happens and after 10mins of trying to escape it I just loose my changes and reload it.

What a pain!

#5

Thank you @oeyoews @TW_Tones.

I agree that the red screen of embarrassment could be improved. We have a long standing problem with unwanted ResizeObserver loop limit exceeded errors (I think they come from YouTube).

From a usability perspective, it is frustrating that users are not given any useful choices other than closing the dialogue.

To help me start thinking about improvements, I’ve made a PR with a modest improvement. It adds a new button to the RSOE allowing the tiddler store to be downloaded as a JSON file. See Enhance RSOE error screen with emergency download tiddlers button by Jermolene · Pull Request #7966 · Jermolene/TiddlyWiki5 · GitHub

Next, I would like to explore adding a button or checkbox to ignore the same error in the future. Ideally, the implementation would persist across restarts, either by saving a config tiddler or using local storage.

lyWiki
lyWiki936×832 108 KB

3 Likes
#6

Thanks for looking at this @jeremyruston

  • As you have addressed, Perhaps the biggest problem with closing the error message is when it is immediately replaces with a similar or identical message and you have to click many times to access the wiki again, even just to save and reload.
    If it helps in other cases browsers often prompt something like “dismiss future dialogues for this message”
    • I was just wondering if we could let the user direct future messages to the consol log without future prompts? This would restore access to the wiki if possible and store the messages in the console for review.
  • I am not sure future messages should be suppressed in the wiki unless specifically requested, except in the current instances. We may inadvertently hide a reoccurring problem with a single click.
    • May be this needs an are you sure? and a reminder on wikis that some messages are suppressed. #1
  • Perhaps an active link to a documentation tiddler on tiddlywiki.com where we can document both the error dialogs and approaches to dealing with them? We can build the resources over time.

On a related matter - I am volunteering.

Perhaps we should include a place to present a notice that one or more messages that have being suppressed could be a new wiki “system info panel” in the control panel? (even hidden by default) I have made one of my own that includes;

  • The current window.name
  • The last modified tiddler(s) and timestamp
  • Last time wiki was loaded $:/info/startup-timestamp
  • Default tiddlers “filter” and current user name

And any other information such as safe mode, local storage if active, url components etc… all which may be relevant to troubleshooting.

  • Any error messages that occurred that we can dump in a tiddler,
  • current tiddler at the time etc…

I would also add a tag that users plugin authors can set to include in the “system info panel”

I would be happy to develop a prototype into which you can add any debug info you can extract from error dialogues.

#7

I just stumbled across another situation when my own code generated a semi-infinite loop. A tool for dropping tags on a tiddler works well, but occasionally, by mistake, I have dropped an existing tag pill on the drop zone and it interprets this as adding every tag on the tiddler;

  • I can fix it with a limit or something but it is a similar use case
  • I mention it in case a more generic mechanisium were possible.
#8

This thread is focused on the JavaScript errors that trigger the red screen of embarrassment. Infinite loops in wikitext or filters is a separate topic.

#9

It may very well be, but in my defence, it may require a very similar code solution.

I have raised this before and the “same error/dialogue is triggered multiple times” and they are very similar, that is we have “no way to dismiss or cancel multiple messages”.