V5.3.2: story river fails to scroll to open linked tiddler ... why? (conflict w plugins that uglify)

A little bit of context, because I think it’s important.

  • Jeremy did a prototype late 2018, which was part of v5.1.18
  • GH user cdruan did extend the whole thing to make it more accessible in March 2021 - It was released with v5.2.0
    • There is a very detailed thread at GH, which shows how the project evolved.
    • There was a discussion to make external-core relatively prominent in the “Right sidebar → Tools tab”
    • It was decided that it should not be so prominent.
  • v5.2.7 got an update to download a single-file-snapshot from an external-core wiki.
    • The other way around is not encouraged.

------ end context

I do highly appreciate the external-core function for advanced users.

  1. I think it’s a perfect match for wikis served from GitHub pages, because it allows us to save back to the web, without a 2MB core overhead. So smaller wikis can be saved fast. Since the core can be cached by the browser only the wiki has to be downloaded if it changed.

  2. I think the same thing is true for tiddlyhost. TiddlyHost is free to use – but somebody has to pay for the transfer volume. IMO that’s the reason, why it makes sense that TiddlyHost wikis also use this version.
    I think everyone who extensively uses tiddlyhost, should consider to sign up for a “Standard Plan”

  3. Locally, I do use it with my local WebDav IIS server for several years now. For me it’s reliable and fast, with basically no system overhead. – But – I do have to say, that I need to use my webdav-lm plugin to counter etag-problems.

  4. I do not use uglified js or UI, because I need the readability for hacking and debugging.

I do have several single file wikis. Most of them are less than 10MByte, which is not really much if compared to modern phone JPG images.

A 12 megapixel image has from 1.5 up to 4MByte per image and most users have 1000+ of them on their phone and happily share them with WhatsApp. I know that they are downscaled, but still.

I personally do not care if I have a 100 - 10MByte wikis. It just does not matter – for my usecases.

Hope that makes sense
-Mario

1 Like

Because of thread-and-reply order, you may not have seen where I confirmed above that I actually have successfully added back all the functionality in one internal-core version, without getting the problem.

Yet I have another virtually identical instance (also based on standard internal-core) that does have the buggy symptoms. As far as I can tell they are identical in function, though I did not follow the same sequence in adding things back in, and there is a small difference in shadow / overridden-shadow count that I still need to troubleshoot.

If this were a one-off incident, I’d say I’m “home free” because I’ve got one functioning version of my site. But at this point the glitch has started independently several times, so I’d really like to solve the mystery of what triggers it before it derails me again. :grimacing:

I did read that, and had done so myself earlier.

But

Like you I still would like to get to the bottom of it, and what is odd is,

We would think we could find it in your original problem wiki.

I’ve been thinking about this…

  1. While it’s true that I’m continually updating this particular wiki – i.e. there are changes being made – with regard to the opening/closing/scrolling behavior (lack, thereof), my additions aren’t going anywhere near that stuff

  2. I’m asking myself what else has changed?

Answer: the story river. All the time.

And of course, that includes changing the history AND the Open tab in the sidebar.

Clue?

3191d457

1 Like

Below I document the cause, a solution and speculate why it has happened.

I just placed this in a tiddler and a sidebar history tab and they seem to be working correctly;

* {{$:/StoryList!!list}}
* {{$:/HistoryList!!current-tiddler}}

I also note although the following are set but the address bar is not changing, like it does on tiddlywiki.com. This is perhaps another symptom of this bug and may point to where the problem lies.

Snag_23970543

Finaly I install my focus tiddler solution on the wiki and it uses a layout and message catcher and is being triggered, yet it does not change the navigation in the wiki, this makes me think a bug lays somewhere in the core code.

  • What is causing it I am not sure
  • A Quick search suggests the eventcatcher is not in use.

I dragged the following tiddlers to the problem wiki then used preview differences to see if they are the same;

  1. $:/core/modules/widgets/action-navigate.js
  2. $:/core/modules/widgets/button.js
  3. $:/core/modules/widgets/link.js
  4. $:/core/modules/widgets/linkcatcher.js
  5. $:/core/modules/widgets/navigator.js

Perhaps it is to do with the uglified, or external core changes to internal core, mentioned before but the core/shadow tiddlers have a number of changes in them, and not on tiddlywiki.com, all starting with something like this;

!function(){'use strict'; function t(t,e){this. Initialise(t,e)}var e=
  • A search for !function(){'use strict'; function in the shadows reveal 371 core tiddlers in Biblio-Springer containing this,
  • The same search reveals none of these on tiddlywiki.com.

A fix

I took the list of tiddlers on Biblio-Springer containing these dubious function calls and exported them from tiddlywiki.com without these functions, imported the new ones into a Biblio-Springer copy, saved and reloaded the whole wiki.

  • The problems are now fixed

A conclusion

Something has resulted in the core tiddlers within Biblio-Springer being changed, I would suggest “corrupted”.

  • looking at the change applied to these tiddlers should tell someone in the know what would have done this, and consider this the cause of this problem.
  • To see all offending tiddlers use advanced search > Shadows and search for !function(){'use strict'; function
  • They are all javascript .js tiddlers but some .js tiddlers may not have this problem
  • Perhaps it was introduced via the external core?

Hi @Springer I had another dig around in https://just-for-troubleshooting.tiddlyhost.com/. The immediate cause of the problem is that the “classic” story view requires that there not be any DOM nodes in between the consecutive <div class="tc-tiddler-frame"> that make up the story river, and yet in this example there is a text node representing a double line break in between each tiddler.

The usual way that this problem is triggered is by creating a view template that accidentally includes additional DOM nodes. In this case, I think the problem is that Uglify is not compatible with one of the changes in v5.3.2 that fixed a problem with the way that white space is processed at the start of a tiddler.

We have an improved fix lined up on GitHub, it would be great if you could try out the preview release at https://tiddlywiki5-git-trim-whitespace-after-pragmas-jermolene.vercel.app/

1 Like

I should have mentioned that there is an upgrader for the preview release here:

https://tiddlywiki5-git-trim-whitespace-after-pragmas-jermolene.vercel.app/upgrade.html

This fact is, in the prerelease for example $:/core/modules/widgets/action-navigate.js does not contain the above. Is that the same problem?

What you are seeing there is the transformations applied to JavaScript modules by the Uglify plugin. That’s why the core modules in this wiki are different than the standard ones.

Wow, thanks @jeremyruston for the close look and diagnosis!

When I post about unexpected TiddlyWiki behavior, much of the time the fault is somehow mine (mistaken css syntax somewhere, etc.). So I’m always sheepish. But when something does turn out to be an issue that could potentially affect others, I’m happy to see that proactive problem-solving on this forum can be very fast.

I easily lose track of the steps needed to re-initiate external core after an upgrade, and I do want to re-introduce external-core mode eventually… (I am happy to wait until @simon sets up an external core template at tiddlyhost for the upcoming version.) At any rate, I’ll keep this project as internal-core for a while, just to be confident that the problem does not re-appear (as @CodaCoder had this behavior come and go, and it seemed to show up or not show up rather randomly in my experiments).

Thanks!

I’m like a cat watching ping-pong here. This has been fascinating. I did start comparing all the settings between the two wikis. And every time I found a difference: “Aha”, only to have it not fix the issue. I could never have found what Jeremy determined… which reinforces for me how much further I have to go in my journey.

Did you ever figure out what plugin was introducing Uglify?

1 Like

I recall from some earlier exchanges here that uglify is incorporated in some plugins by @Mohammad. I don’t recall which ones, but several of Mohammad’s plugins are essential to my work (especially the biblio site), so the idea of assembling a version without those plugins, in order to troubleshoot an intermittent/whack-a-mole problem, was not looking good!

Actually, I found this thread where Mohammad seems to be indicating that all kookma plugins incorporate uglify…

IMPORTANT NOTICE
From Tiddlywiki 5.2.3, the packaged form of kookma plugins are distributed as minified tiddlers. The minification are done using Uglify from Flibbles.

I don’t really understand the difference between uglifying only some elements (within a plugin) and uglifying the whole wiki — which apparently was happening with my wikis (without my ever invoking such a process directly), given the discrepancy in some core shadow tiddlers, noticed by @buggyj above.

@Mohammad I'd like to request, please, that you find a way to release your plugins without uglify-ing the source. Debugging this issue has used up far too many person-hours. Thanks!

As @Mohammad pointed out, this isn’t actually the case any more.

The source for these plugins is available on GitHub. So we can repackage them relatively easily.

If you need help getting versions of these plugins without the uglification, please let me know. If you’re comfortable with the command line and don’t mind installing Node and Git, I can give you instructions. If not, I can do them for you. I’ve just done it for RefNotes. Of course, even better, as @CodaCoder says, would be if @Mohammad can offer both versions. But I haven’t seen much of him lately.

The version on Kookma is 43,031 bytes. When I packaged it as source it’s 60,284. So uglification reduced it by 30%, which is meaningful but perhaps not important enough to insist on it.

1 Like

Dear all,

Sorry for the late reply. I will update the plugins without Uglify, but if you kindly be patient for a few days to use the new planned TW 5.3.3.
The current structure of kookma plugin repos is:

  • Demo + minimized plugins using GitHub pages (it seems most users like to drag and drop plugins into their Wikis)
  • Source code (useful for who use TW on Node.JS)
  • Minimized packaged plugin (also works as drag and drop)

From TW 5.3.3 onward, I will publish demo+plugin without minifying.

Again, I appreciate your patience and sorry for not being more active on the forum.

3 Likes

The issue is with Uglify. There is a report of issue on GitHub by Mohammad.

For those use kookma plugin, they can install latest kookma plugins from CPL (Chinese Community Plugin Library) without minimizing (no Uglify)

2 Likes

Hi @CodaCoder
The source is not uglified! Only the packaged one (also distributed in demo page). Please see my recent reply in the thread.

1 Like

Reading through this thread, I’m wondering if it would be better to stop uglifying the external core js on Tiddlyhost.

The size differences are as follows:

 2349000 tiddlywikicore-5.3.3.js
 1355873 tiddlywikicore-5.3.3.min.js

 424214 tiddlywikicore-5.3.3.js.gz
 291541 tiddlywikicore-5.3.3.min.js.gz

I expect most browsers fetch the gzipped version and cache it, so the benefit is a roughly 30% smaller one-time download. Maybe that benefit isn’t worth the extra difficulty it brings with troubleshooting and debugging.

Are there any arguments in favor of keeping the uglification? If not I’ll probably remove it soon from the “external core” TiddlyWiki on Tiddlyhost.

1 Like

I think @saqimtiaz mentioned the he has some users with very limited data plans or really limited mobile connectivity. @saqimtiaz what do you think about the minified core?

Perhaps its not as importiant to minify a core that is externalised for all tiddlyhost site?