Not that I want this trouble to be widespread, but I do feel a bit more sane to learn that someone else has seen this behavior recently.
This is helpful, thanks. The commander plugin and edit-tabs plugin each caused no trouble on import (+save +reload), but perhaps there’s some additional factor in my wiki that plays badly with these in v5.3.2…
This is indeed odd. Especially since links do seem to be rendering fine visually, and turning this parsing rule off should prevent such rendering, no?
This is the linkstyle solution I use on all my projects. It’s just css, should not affect any activity.
This is a good question to pursue…
However, this version of the wiki is NOT external-core, and has the same problem: https://just-for-troubleshooting.tiddlyhost.com/ …
UPDATE: Now I’ve got two contrasting versions of the site uploaded to tiddlyhost, both internal-core. (So, perhaps easier to troubleshoot. And good to rule out external-core as the cause.)
SUCCESSFUL rebuild of the site starting from empty.html — behaving well at my minimalist-test-mode address.
FAILED rebuild version (with “failure-to-scroll-to-link” syndrome): https://just-for-troubleshooting.tiddlyhost.com/ …
One has the problem, one does not. I need to turn to other tasks, but if anyone is clever enough to find a smoking-gun difference between these two, that might be the next step.
Given the experience @CodaCoder had, we might be looking at some brittle detail that’s hard to replicate.
Since v5.3.0 the default setting to wikilink CamelCase links in empty.html was set to “disabled”, since the community requested it.
There is nothing strange about this one. See: https://tiddlywiki.com/#Release%205.3.0
Thanks. I had indeed initially thought this parsing setting was about CamelCase links (which I’ve disabled for years), but then convinced myself otherwise by reading this documentation about wikilinks — plus trusting that @TW_Tones was probably right to be surprised by that detail.
So, to be clear, I now have two contrasting versions, including one internal-core version that shows the symptoms: https://just-for-troubleshooting.tiddlyhost.com/
I’ve also proven to myself that I can rebuild the site from empty.html and not have the problem. But I have NOT been able to isolate the difference between the bad version and this good one: https://minimalist-test-mode.tiddlyhost.com/
I realize the uglification still makes it hard to troubleshoot. I’m not sure exactly which plugins trigger the uglify, though.
And, do I recall correctly that once uglify has been activated, disabling those plugins doesn’t actually un-uglify? (If so, just disabling those plugins won’t make it easier to troubleshoot, correct?)
I could try to put time into attempting to replicate the link-scroll problem without importing those uglifying plugins. (But if RefNotes is among the plugins with uglify, then we’re talking about removing plugins that are essential to the nature of the site…)
In my case, it’s true I modified .../SideBar/Open – I often do:
My wiki is now working, so it’s not that 
I create a new external core wiki on tiddlyhost and dragged $:/core/ui/SideBar/Open from tiddlywiki.com on to https://testincludecore.tiddlyhost.com/ - imported it then compared - they are different -
Thanks. But while @Springer mentioned she does like to run with external core, I don’t do that. Red-herring?
Be interesting to see what @jeremyruston/@pmario think.
Interesting mystery.
Perhaps now is time to attempt to intentionally add back the functionality that is missing and perhaps that will shed light on the problem eg navigate message or event catcher.
Just a note: the problem when its occuring effects more than open links, recent and others.
A little bit of context, because I think it’s important.
------ end context
I do highly appreciate the external-core function for advanced users.
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.
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”
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.
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
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. 
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…
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
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?
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.
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.
I dragged the following tiddlers to the problem wiki then used preview differences to see if they are the same;
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=
!function(){'use strict'; function in the shadows reveal 371 core tiddlers in Biblio-Springer containing this,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.
A conclusion
Something has resulted in the core tiddlers within Biblio-Springer being changed, I would suggest “corrupted”.
!function(){'use strict'; function
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/
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!