Comment 5 for bug 1689488

Well, to some extend today I accidentally found that the default sdl frontent might have this issue as well.
If you start qemu by cmdline and e.g. just give it an ISO.
You need to slow that X11 connection down e.g. by running this via X11 forwarding across an ocean.
So the handling gets sloggy, which is fine (distance is distance, latency is ok).
Now in the framebuffer console make it roll the full console which is as easy as typing commands until the console is completely full and then do
- CTRL+C (will go down one line causing a lot of transfer)
- Immediately roll 1-0 on your keyboard
=> Result is that quiote often (>50%) only chars 1-7 or 1-8 appear.

Anyway that is even with Qemu 2.10 so no fix to port for that.
But related enough so I wanted to mention it.

Trying to reproduce:
1. Taking a recent desktop Ubuntu
   $wget http://cdimage.ubuntu.com/daily-live/current/artful-desktop-amd64.iso
2. starting that with "normal VNC" (and websocket)
   $ sudo qemu-system-x86_64 -enable-kvm -cdrom artful-desktop-amd64.iso -m 8192 -smp 8 -vnc 0.0.0.0:1,websocket=5701
   (Note this system is remote to increase latency and burst)
3. attach novnc
   (Whatever I tried, it didn't let me connect successfully to the 5701 websocket port that I spawned directly, so going via the novnc proxy.)
   $ git clone git://github.com/novnc/noVNC
   $ cd noVNC
   $ ./utils/launch.sh --vnc 10.245.168.50:5901
   # Point your browser at "http://127.0.0.1:6080/vnc.html?host=127.0.0.1&port=6080" or as
   # instructed in your case
4. I copied some large chunks of text around with mouse copy, with fast keyboard inputs, ...
   I couldn't make it break after 8 chars with the qemu in Xenial.

@ustcweizhou - could you describe your vnc setup in detail that was affected by it?
Because if it is close to my current sdl finding than the fix wont help.
And if it is not then I need your details to reproduce and verify the fix afterwards for an SRU process.