Stop the logger from creating alert tiddlers on the server. They
propagate to the client but are not deletable from the client because
they are in the `$:/temp` namespace.
cc @loleg
The previous fix changed the scrolling behaviour such that it only
scrolled to the top of a tiddler if the tiddler was entirely offscreen.
It wasn’t entirely satisfactory because scrolling was prevented even if
only a few pixels of a tiddler are in view. This commit ensures that
the scroll does occur if less than 50 pixels of the target is in view
@aelocson here’s an alternative fix for #981, as discussed in
https://github.com/Jermolene/TiddlyWiki5/commit/691e5719a4ff74a04d389bd1
26ba2a69e7651a2a#commitcomment-9848682
It does seem a lot nicer. It avoids the problem you raised, and also
avoids scrolling when a permalink is used.
I suspect that we’d need to make the hard-coded 50 pixels be
configurable.
Cecily and Zoomin story views use a document.body that is smaller than
the document.documentElement. We were just clearing the popups on
clicks on the document.body Clicks on the document element (ie, on the
background of the page) were not being trapped, meaning that you
couldn’t dismiss a popup.
@felixhayashi I’m afraid I haven’t used your pull request as there were
a few details that I wanted to do differently. The main change is that
these changes allow both a param string and hashmap to be specified.
With this commit tag pills will now choose for the foreground colour
either the current palette “foreground” or “background” colours,
according to which has the higher contrast. It’s something @gernert has
expressed an interest in in the past, and I’ve tended to agree that it
is a nice piece of polish. It opens up the possibility of paler colours
for tag pills than are currently possible.
The trouble is that in order to implement it I’ve had to bring in a
third party library for parsing CSS colours. It weighs in just over
9KB, making quite a lot of weight for such a small feature. I don’t see
any other immediate uses for the colour parsing library either.
So, I’m undecided at the moment whether this should stay in the core.
There are still some warnings about making functions in a loop, but
I’ll fix those as a separate pull request because the fixes are more
than typographic errors.
Re-introduces the “tw-auto-save-wiki” message. The previous approach of
automatically triggering autosave whenever a tiddler changed meant that
changing configuration changes in control panel was triggering an
autosave. Using the explicit message gives us better control of the
situations in which we’ll autosave.
Now we solve the earlier problem of there being outstanding tiddler
change events at the time that we process the “tw-auto-save-wiki” by
deferring the autosave until the outstanding change event comes in.
Previously we were using a message `tw-auto-save-wiki` to trigger an
autosave. The message was generated by certain UI actions such as
saving a tiddler. The trouble was that the message was being processed
before the wiki change event for the accompanying change had had a
chance to percolate. The end result was that the dirty indicator was
staying lit when using autosave.
The new approach abandons the autosave message and instead triggers the
autosave in the wiki change event when a relevant change occurs.
One happy side effect of these changes is that the dirty indicator now
works as expected with the client server edition - ie, when typing in a
draft tiddler the dirty indicator will flash briefly, and then clear
when the sync mechanism has completed saving the draft.
Importing an encrypted wiki ordinarily doesn’t place the password in
the password vault on the basis that one ought to be able to import
from a file without automatically inheriting its password.
Now there’s a configuration option that can be used by the upgrade
plugin to cause the password vault to be updated with any password
entered by the user. The end result is that the user only needs to
enter their password once.
Previously any refreshing of the content of a modal would cause a
crash. The problem is the way that we steal the root widget for the
render trees used in the modal. The root widget is tied to the
container DOM node for the main content area, which isn’t actually a
parent of the modal DOM nodes, hence the confusion for the refresh
mechanism.
