I can reproduce this in Firefox but not in Chromium, on a slowish Ubuntu machine.

Hi Moriel, David, can you please specify on which wiki this happens?
I am not able to reproduce it on en.wp or it.wp,
but it does happen on mw.org - even if you do not use the Bold button or the new features, like another user suggested.
I'd say this bug probably needs to be renamed.

<<First, I noticed a strange behavior where anything I typed at the end of that third line, if I then hit enter, it would be duplicated in the fourth line, and my cursor would move to the fifth (blank) line. I then took a look at the wikitext generated by VE, and it looked odd, so I copied it into a wikitext editor, and got a rather different looking result than VE was showing. Also, upon saving with VE, I got this result, which is the same as copying into wikitext editor, but not what VE was showing me. Chris857 (talk) 20:54, 25 August 2013 (UTC) >>

http://www.mediawiki.org/w/index.php?title=User:Chris857&oldid=770602
http://en.wikipedia.org/wiki/File:Visual_Editor_-_subscript_and_superscript.PNG
http://en.wikipedia.org/wiki/File:Wikitext_editor_-_subscript_and_superscript.PNG

The user think this is related to the new super/sub script features.

I don't think it has to do with them. Proof is, I can reproduce (on Mediawiki) the same bug without using them. You just need to add quickly casual sequences of words, as if you were vandalizing the page. In this diff http://www.mediawiki.org/w/index.php?title=User:Elitre_(WMF)/SandboxVE&diff=prev&oldid=771184 I kept writing on the third line, it was VE which splitted what I wrote on more lines. I was also able to reproduce the difference among the content you "write" and the one which is saved. I can recall a vaguely similar behavior (not with casual letters though) when starting a list, but I can't say which bug that would be. I am also not sure whether this is a real bug or some counter-vandalism filter in action :)
Thanks.

This is problematic, since I couldn't properly and reliably replicate the bug since then, it only happens occasionally, I'm not sure if it's because of the speed or some other aspect.

But I did find that it happens not only with the Bold button - it happens either with "just" rapid text (no annotation) and with strikethrough and italics as well. I think it's probably safe to say that this isn't a specific annotation bug.

Another small detail about that bug was that once it *does* happen, the rest of the editing is a mess -- that is, once it happens, even if I stop rapid typing, and then start editing normally, I still get random letters and gibberish added, and the 'delete' functionality goes wonky. To get rid of it I need to refresh the page and start over.

Also, This happened on my local wiki (using current VisualEditor master), installed on Ubuntu 13.04, and used through Firefox, and I just replicated it in MediaWiki.org

I can reproduce this just by holding a key down for a few seconds. It seems to be because of setTimeout( f(), 0 ) causing event handling to overlap. This could be challenging to resolve because of the way browser event handling works. Gory details below :-)

On my slow Ubuntu laptop, I can reliably reproduce the bug. It happens if I just hold the 'x' key down inside a <h1> for a couple of seconds.

I'm pretty sure it's happening because we use setTimeout to process events. This can get complex up when two events are emitted by the browser at virtually the same time. In this case, ve.ce.SurfaceObserver.onDocumentKeyDown receives event 1, does some processing, then effectively does a setTimeout( f(), 0 ) to finish the processing. But by that time, the browser has already queued the handlers for event 2, so the processing for event 2 will start before the processing for event 1 has finished.

I tested this by putting two lines at the top of onDocumentKeydown: a ve.log("main...") and a setTimeout( ve.log("post..."), 0) . The corruption happens exactly when we get "main..." twice in a row followed by "post..." twice in a row. See http://pastebin.com/dzGYbpDq for full output.

This may be challenging to resolve, because we probably need to do stuff both before and after the browser's native keydown handler. We can't manage all the handling in our own queue, because (afaik) the browser's native handling can't be postponed. So it seems the only obvious option would be to detect when there are overlapping events, and try and do act delicately enough that things don't break.

Timo, any thoughts?

Change 81213 had a related patch set uploaded by Divec:
Detect outdated pending post KeyPress handler

https://gerrit.wikimedia.org/r/81213

Further to my previous comment: it seems that it's actually onDocumentKeyPress which is doing the setTimeout which gets outdated; and that we can code our way around it because it's just there to do a surface-to-model poll.

Change 81213 merged by jenkins-bot:
Detect outdated pending post KeyPress handler

https://gerrit.wikimedia.org/r/81213

• Bug 53317 has been marked as a duplicate of this bug. ***