* jQuery: Migrate to `.on()`, `.off()`, `.trigger()`
This avoids methods that are deprecated in newer versions of jQuery.
* jQuery: avoid `.removeAttr`, prefer `.prop`
* helper.edit: wait up to 10 seconds for ACCEPT_COMMIT
* Chat: disabled attribute is boolean
* Chat: avoid inline onclick handler to support jQuery 3.4+
* jQuery: update to version 3.6.0
* Update to 3.7
* Removed deprecated event.
* Revert change to focus on padeditor.ace
---------
Co-authored-by: webzwo0i <webzwo0i@c3d2.de>
The old "switch to pad" logic looked buggy, and it complicates pad
initialization. Forcing a refresh after importing an `.etherpad` file
isn't much of a UX downgrade.
When settings.useMonospaceFontGlobal is set to `true`, it sets the default
font to 'monospace'. This font seems to have been removed in
a5164dad43.
This commit sets the default font to "RobotoMono" which is a valid
option.
Tested in a Docker environment, setting `PAD_OPTIONS_USE_MONOSPACE_FONT`
to `true`
Signed-off-by: Xavier Mehrenberger <xavier.mehrenberger@gmail.com>
This will make the pages gracefully handle HTTP server restart events,
which happen whenever a plugin is installed or uninstalled via the
`/admin/plugins` page.
Normally I would let `eslint --fix` do this for me, but there's a bug
that causes:
const x = function ()
{
// ...
};
to become:
const x = ()
=> {
// ...
};
which ESLint thinks is a syntax error. (It probably is; I don't know
enough about the automatic semicolon insertion rules to be confident.)
This will be a breaking change for some people.
We removed all internal password control logic. If this affects you, you have two options:
1. Use a plugin for authentication and use session based pad access (recommended).
1. Use a plugin for password setting.
The reasoning for removing this feature is to reduce the overall security footprint of Etherpad. It is unnecessary and cumbersome to keep this feature and with the thousands of available authentication methods available in the world our focus should be on supporting those and allowing more granual access based on their implementations (instead of half assed baking our own).
Rather than reinvent the wheel, use a well-tested library to parse and
write cookies. This should also help prevent XSS vulnerabilities
because the library handles special characters such as semicolon.
