Text can suddenly be trapped into a not-very-wide box for no apparent reason

[paulproteus]

Steps to reproduce:

• Create a new Etherpad grain

• Clear all text within it

• Copy this single line of text, with a space at the end of it, to the clipboard:

But maybe the rain isn't really to blame. So I'll remove the cause, but not the symptom.

• Paste it a few times

Expected behavior:

• Every line (except possibly the last line) in the paragraph takes up the full width of the page.

Actual behavior:

• Etherpad appears to introduce some line wrapping, sometimes mid-word.

Screenshot:

[paulproteus]

The user who reported this to support@ found that their text was trapped in a much skinnier width than mine is, so the title of the bug report may seem like exaggeration, but I believe it accurately expresses the intent of the person who originally reported it to support@.

[kentonv]

This appears to be happening here:

https://github.com/kentonv/etherpad-lite/blob/sandstorm/src/static/js/contentcollector.js#L718

This forces a wrap at 2000 characters. You can actually go back and delete the newline to get the line longer than 2000 chars again, but as soon as you edit the line, it breaks again.

Possibly our friend on support@ ended up with multiple breaks because he went back and added more text earlier in the paragraph, causing the end of the paragraph to be repeatedly chopped off.

2000 chars seems like a weirdly low limit for a paragraph. But Etherpad was originally meant to be a code editor, I think. Perhaps this limit goes all the way back to AppJet days. It does appear to go back to the first days of etherpad-lite.

It's weird that none of us have run into this problem before.

Probably, we can increase the limit, though the comments around it suggest that making it infinite would be problematic. What would be a good number?

[paulproteus]

4096000 seems like a good number. What are the trade-offs involved?

[paulproteus]

I went and read the source. Thank you for the link, btw!

https://developer.mozilla.org/en-US/docs/Web/API/Document/designMode doesn't show me much about design mode's performance trade-offs. I think little is documented about the performance trade-offs.

I think my friend @RoanKattouw might have more input on this, since he used to work on the Wikimedia Foundation's VisualEditor. Roan, how bad would it be if we have a 4096K-byte line in designMode? :)

[kentonv]

What if I were to tag @dgreensp and ask him since it looks like this code may be so old that he may have written it? :D

David, do you remember why Etherpad limits lines to 2000 characters? Is this limit likely obsolete these days?

[dgreensp]

I wrote this code. :)

The limit was originally put there with unwrapped documents in mind. The relevant case is:

1. User pastes in some giant text, with no line endings
2. Document is not in wrap mode, so the text appears on one line that extends very far to the right-- hundreds of thousands of pixels
3. Firefox used to crap out when coordinates exceeded 32k pixels, because it positioned platform-native widgets in 16-bit coordinates. It also seemed unlikely that the user really wanted such a ginormous line.

A low limit shouldn't be necessary from a technical standpoint.

[kentonv]

Hooray! Since Etherpad on Sandstorm almost always operates in wrapped mode I suppose we should simply remove this limit.