idupree / hilarious-text-editor Goto Github PK

I managed to launch it, but how do I do all the other things?

A Readme could tell me :)

Apparently browsers keep programmatic changes to a textarea in the textarea's undo history. At least some of them. Firefox does; Chromium doesn't. (Testing on Linux - there could well be OS differences too.)

There's no API to change a textarea's undo history. (Unless my Google-fu failed me;. I found a 2012 draft of an undo api but no evidence it made it into any spec or implementation.) However you can possibly create another textarea and delete the old textarea to clear the undo history (or at any rate, that would likely prevent the undo history from doing catastrophically wrong things). On Firefox, programmatically changing the textarea could be used to initialize an undo history, but that doesn't seem cross-browser enough to bother. (Particularly since Firefox is not a great browser to use with this editor, due to a reflow issue with Firefox, and since Dragon seems to work best with IE. It's possible IE also behaves this way, in which case it might be worth doing.) In any case, I don't want things to be more broken than they have to be on Firefox, so that means creating each new textarea with its initial contents already in it so that you can't undo yourself to an empty file by accident and delete all your work. For example, I can do this by something along the lines of createElement('div').innerHTML = '<textarea>'+escape(textareaContents)+'</textarea>'.

The undo stack is per-textarea in Firefox, but per the entire page in Chromium. In Chromium, when you undo, it focuses the textarea that you are undoing in, and makes the change. Except that if that textarea is display:none at the time, then it makes no change instead. This means you can generate infinite text by

1. type something in a textarea
2. make the textarea display:none
3. undo (Ctrl-Z)
4. make the textarea display:block
5. redo (Ctrl-Shift-Z)
6. go to step 2 (unless bored)
7. profit???

This issue also means the Firefox textarea-reflowing workaround maybe should be scrapped, because the workaround messes up the undo history in Firefox. Instead, make the textarea longer-than-necessary just in case, and warn the user that the line numbers may be wrong sometimes (particularly if the user has verrrry long lines, but even a single wrapped line is occasionally enough to cause this problem depending exactly where the spaces are in the line and depending on luck.)

I've found no way to detect the problem programmatically. Firefox is too confused to adjust scrollHeight to be the abnormally large height that it needs to be when this happens, and it doesn't happen in the same way in the #testline textarea. TODO: create textcase and submit to moz bugzilla; searching https://www.google.com/search?q=textarea+reflow+scrollHeight+site%3Abugzilla.mozilla.org didn't find any that appeared relevant.

It scrolls all the way down, rather than just one page down, at least with Firefox Linux keyboard PageDown and IE Dragon pagedown. Mirror problem with PageUp.

• fix line wrapping estimate
• check if tabs are preserved
• consider whether to make it easier to enter tab characters