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.
We were parsing the boot tiddlers, making them into a widget and then
refreshing the widget tree. The problem is that subsequent chances to
the boot tiddlers themselves wouldn’t be picked up as part of the
refresh.
Now we indirectly parse those UI boot tiddlers through a transclusion,
which does get refreshed in the desired way.
1. Moved some methods out of boot.js because they are not needed until
after bootup
2. Added alternate message for editing an overridden shadow tiddler
3. Minor style tweaks
This is an experimental module to help us measure the performance of
the refresh cycle and the filter mechanism. Not intended to replace the
performance measurement features in browser developer tools, just to
make it easier to automate performance checks cross-browser.
The immediate purpose is to help in refactoring the filter mechanism.
The recent change to encapsulate the wiki store “tiddlers” object has
hurt the performance of filters, and it’s going to be helpful to have
decent measurements while refactoring that code.
I’m still not convinced that this stuff should be in the core, and may
well end up removing it after the present refactoring cycle.
