We were using `String.prototype.replace()` without addressing the
wrinkle that dollar signs in the replacement string have special
handling. This caused problems in situations where the replacement
string is derived from user input and contains dollar signs.
Fixes#2517
This is quite a big change: a new way to invoke action widgets.
The advantage is that it solves #2217 and #1564, a long running problem
that prevented us from adding action widgets to widgets that modify the
store.
This commit adds the new technique for the button and keyboard widgets,
but also extends the select widget to trigger action widgets for the
first time
Allow widgets to choose not to propagate actions. This is important for
widgets that themselves trigger actions.
Note that this change will cause problems with any existing
5.1.8-prerelease plugins that call `invokeActions()`.
Preserves compatibility with existing invokeActions call in button widget by creating a separate 'invokeActionCall' function to carry out the recursion. Triggering all descendants permits use of action widgets inside list widgets or macros. Also makes it possible to add triggering capability to select widget.
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.
Previously, widgets were reading variables from themselves or their
cascaded ancestors. That means that if a widget sets a variable and
then reads the same variable, it will get the same variable back. That
sounds reasonable, until you consider a widget that wants to modify a
variable - eg the tiddler macro. For example:
```
<$tiddler tiddler={{!!report}}>
<$transclude mode="block" />
</$tiddler>
```
Here we first evaluate the `{{!!report}}` reference, which involves
reading the currentTiddler variable, looking up the tiddler, and
retrieving it’s `report` field. The next the tiddler widget is
refreshed, it will use the newly set currentTiddler as the basis for
resolving the `{{!!reference}}` reference.
The fix is to get variables from ancestors, but continue to set them on
ourselves.
Because:
* It doesn't work well with TW5's refresh mechanism, which relies on
being able to regenerate any portion of the DOM as required; this
frequently causes inline handlers to be re-executed at unexpected times
(see
http://tiddlywiki.com/static/TiddlyWiki%2520for%2520Developers.html)
* It mixes TW5 version-specific JavaScript with user content
* In multiuser environments there is a security risk to importing or
viewing tiddlers you didn't author if they can have JavaScript in them
One consequence of wikifying macro attributes before use was that we
couldn’t have tiddler titles with wikitext syntax in, which was
definitely a problem.
Jermolene