document.location gives us an URL encoded version of the original
filename, so we decode it to recover the original filename for saving.
Fixes#2828Fixes#2819
Now the `tm-download-file` and `tm-save-file` messages use the hashmap
to specify variables to be applied when rendering the tiddler.
We also add a convention that the variable “filename” is used to
specify a filename for the download.
Causes the wiki to be autosaved whenever clicking “done” after editing
a tiddler. Only works with savers that support autosave. We should
probably make autosave configurable
We were re-using the `tw-save-wiki` message both for saving the current
wiki and downloading a new wiki. Now we’ll use the separate
`tw-download-file` message for downloading.
Fixes#236
We don't need to encodeURIComponent at all when using blob links.
The data never goes into the dom directly, just a guid reference.
This makes saving with blobs very fast!
This should fix crashing on large wikis under chrome
see chrome bug: https://code.google.com/p/chromium/issues/detail?id=103234
This should also speed up generating the download html by a couple of seconds
it avoids repeatedly marshalling the base64 encoded href string across the sandbox boundary
it avoids some time and memory consumed by "large" dom manipulation
major remaining delay is in encodeURIComponent
TODO: consider using iconv on the server
TODO: consider async invocation of regular expressions to avoid client "lockup"
Conflicts:
core/modules/savers/download.js
