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 makes it possible to disable `contentEditable` for certain
elements in some circumstances (e.g., on links so that users can click
on them normally).
* Fix line numbers top padding
This old rule was conflicting with new css rules introduced in 1.8.4
* Fixes#4228 Performance degradation for long pads
Due to layout trashing when calculating new heights
The server is fine with atext.text being an empty string, but the front end is
not, and crashes.
It is not clear if this is a problem in the server or in the client code, and
this is a client-side hack fix. The underlying problem needs to be
investigated.
See for reference:
- https://github.com/ether/etherpad-lite/issues/3861
No more javascript to change css properties
Remove a number of useless tables
Try to stop positioning elements with absolute, but use flex-boxes instead
Adds comment to pad template, and move popups and chatbox inside editorcontainerbox (so absolute positioning is straightforward)
Make the design more consistent: always use base color, font-family and font-size. USe relative font size if necessary (.9rem instead of 11px for example)
Remove two columns in the popups, just use one column
Remove css meant to support old browser (like -webkit-box-shadow, -moz-box-shadow). Those css rules are quite common now, and If we want to support very old browser, we should use clean-css or other tools to add them automatically
Clearing the authorship colors of a document with at least two authors, and then
undoing that action caused a disconnect from the pad.
This change disallows undoing clearing authorship colors in order to prevent
the problem from affecting users, and adds the relative test coverage.
This is a change of behaviour, and is documented in the changelog.
Fixes#2802 (sidestepping it).
This is documented to be more performant.
The substitution was made on frontend code, too (i.e., the one in /static),
because Date.now() is supported since IE 9, and we are life supporting only
IE 11.
Commands:
find . -name *.js | xargs sed --in-place "s/new Date().getTime()/Date.now()/g"
find . -name *.js | xargs sed --in-place "s/(new Date()).getTime()/Date.now()/g"
Not done on jQuery.
When comparing original content with the changes made by the user, we
need to ignore some line attribs that are added by content collector,
otherwise we would consider the change started on the first char of the
line -- the '*' that is added when line has line attribs.
In order to be able to handle both #3354 and #3118, we need to take into
account both the styles attribs (to fix#3354) and the line attribs
defined by any of the plugins (to fix#3118), but we can ignore those
extra line attribs that are added by Etherpad and do not add any
functionality (`'lmkr', 'insertorder', 'start'`).
* Add scroll when it edits a line out of viewport
By default, when there is an edition of a line, which is out of the
viewport, Etherpad scrolls the minimum necessary to make this line
visible. This makes that the line stays either on the top or the bottom
of the viewport. With this commit, we add a setting to make possible to
scroll to a position x% pixels from the viewport. Besides of that, we
add a setting to make an animation of this scroll.
If nothing is changed on settings.json the Etherpad default behavior is
kept
Users still cannot choose which shortcuts they want to enable/disable,
so it does not make sense (yet) to have a cookie with that preference.
This can be reverted once we create an UI to change shortcuts, but
PLEASE PLEASE PLEASE do not read the cookie every time handleKeyEvent is
called!!!
This is an adjustment to #2891.
When checking the places on text that are identical between content
before and after a changeset, we were considering only the standard
(Etherpad-core) attributes, and not taking into account attributes
created by the plugins. One consequence was that the '*' marker of lines
with line attribs were being kept, even when the new lines have
different line attribs. See #3118 for more details.
Fix#3118.
Without this change, a top margin on any element on the first line of pad
content would throw off the alignment of line numbers. The default stylesheet
doesn't define any elements with top margins, but plugins might. (This is also
explained in a code comment.)
In order to see the problem, add the following clause to `iframe_editor.css`
(before incorporating this commit):
#innerdocbody > :first-child {
margin-top: 100px;
}
