Addresses GH #3484
As far as I can tell, the popup level checks in this module are
meant to handle nested popups. It seems to me that the goal is
for at most a single hierarchy of popups to exist at any given time
- bearing that in mind, this change checks any popups currently tracked
by the module, canceling any that don't share an element hierarchy with
the new popup.
* Make modals display in source Window
this makes modals display within the window where they got opened, with the parameter `rootwindow` that, if `yes` or `true`, shows the modal always in the root TW window (`<$action-sendmessage $message="tm-modal" $param="mymodal" rootwindow="yes|true"/>`)
* pass the full event to $tw.modal.display
we need the event there to find `srcDocument` and `srcWindow`
* pass event in options object
* update modal.js to use options.event
* add docs for rootwindow tm-modal attribute
* make triggerPopup optionally set state directly
* update button widget for new state attributes
* update reveal widget for new state attributes
* fix errors in button widget
this allows using the pagescroller for scrolling elements into view where the rect gets calculated somewhere else
Example: CodeMirror has the `cm.cursorCoords()` function that returns the rect of the textselection (or cursor coordinates)
this scrolls the cursor or text selection into view using tiddlywikis pagescroller:
`$tw.pageScroller.scrollIntoView(undefined, function() { return self.cm.cursorCoords(true,"window"); });`
* correct scrolling with tc-adjust-top-of-scroll
not multiplying `offset` with t causes jumps at the first animation steps, where the offset value is bigger than `endY - scrollPosition.y`
* correct scroll offset
* Module-ize server routes and add static file support (#2510)
* Refactor server routes to modules
New module type: serverroute
Caveats: Loading order is not deterministic but this would only matter
if two route modules attempted to use the same path regexp (that would
be silly).
* Add static assets plugin
This plugin allows the node server to fetch static assets in the /assets
directory. I felt that this was a feature that goes above the core
functionality. That is why I added it as a plugin. with the modular
route extensions this was a breeze.
* Add serverroute description to ModuleTypes
* Coding standards tweaks
* Fix filename typo
* Move support for attachments from a plugin into the core
* Missing "else"
* Refactor server handling
* Introduce a new named parameter scheme for commands
* Move the SimpleServer class into it's own module
* Deprecate the --server command because of the unwieldy syntax
* Add a new --listen command using the new syntax
For example:
tiddlywiki mywiki --listen host:0.0.0.0 port:8090
* Add check for unknown parameters
* Add support for multiple basic authentication credentials in a CSV file
Beware: Passwords are stored in plain text. If that's a problem, use an authenticating proxy and the trusted header authentication approach.
* Refactor module locations
* Rename "serverroute" module type to "route"
* Remove support for verifying optional named command parameters
The idea was to be able to flag unknown parameter names, but requiring a command to pre-specify all the parameter names makes it harder for (say) the listen command to be extensible so that plugins can add new optional parameters that they handle. (This is particularly in the context of work in progress to encapsulate authenticators into their own modules).
* Refactor the two authenticators into separate modules and add support for authorization
* Correct mistaken path.join vs. path.resolve
See https://stackoverflow.com/a/39836259
* Docs for the named command parameters
I'd be grateful if anyone with sufficient Windows experience could confirm that the note about double quotes in "NamedCommandParameters" is correct.
* Be consistent about lower case parameter names
* Do the right thing when we have a username but no password
With a username parameter but no password parameter we'll attribute edits to that username, but not require authentication.
* Remove obsolete code
* Add support for requiring authentication without restricting the username
* Refactor authorization checks
* Return read_only status in /status response
* Fix two code typos
* Add basic support for detecting readonly status and avoiding write errors
We now have syncadaptors returning readonly status and avoid attempting to write to the server if it's going to fail
* Add readonly-styles
We hide editing-related buttons in read only mode
I've made this part of the tiddlyweb plugin but I think a case could be made for putting it into the core.
* Add custom request header as CSRF mitigation
By default we require the header X-Requested-With to be set to TiddlyWiki. Can be overriden by setting csrfdisable to "yes"
See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Protecting_REST_Services:_Use_of_Custom_Request_Headers
* Add support for HTTPS
* First pass at a route for serving rendered tiddlers
cc @Drakor
* Tweaks to the single tiddler static view
Adding a simple sidebar
* Switch to "dash" separated parameter names
* Typo
* Docs: Update ServerCommand and ListenCommand
* First pass at docs for the new web server stuff
Writing the docs is turning out to be quite an undertaking, much harder than writing the code!
* Get rid of extraneous paragraphs in static renderings
* Rejig anonymous user handling
Now we can support wikis that are read-only for anonymous access, but allow a user to login for read/write access.
* More docs
Slowly getting there...
* Static tiddler rendering: Fix HTML content in page title
* Docs updates
* Fix server command parameter names
Missed off 30ce7ea
* Docs: Missing quotes
* Avoid inadvertent dependency on Node.js > v9.6.0
The listenOptions parameter of the plain HTTP version of CreateServer was only introduced in v9.6.0
cc @Drakor @pmario
* Typo
These changes allow drag and drop to work with one issue: <a> links are
not draggable; draggable divs, spans, buttons etc. seem to work fine.
There’s some issue with IE11 that I don’t understand.
For testing, you can force links to become spans by changing line 64 of
$:/core/modules/widgets/link.js to:
var domNode = this.document.createElement("span");
The problem was that `this.responseText` crashes for non-text data. We
fix it by letting the client specify which property should be returned.
@ericshulman does this work for you?
This may cause backwards compatibility problems for people relying on
the block mode parsing, but it’s much better for the rest of us as it
avoids an unsightly paragraph tag
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.
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.
Now we get decent visual indication of sync errors, for instance. Still
work to do to coalesce alerts so that the screen doesn’t fill up with
them after an interval. And probably we should add a button to clear
all alerts.
