GNOME Bugzilla – Bug 730763
Sometimes vte is born sick, doesn't properly update display
Last modified: 2015-09-17 22:07:34 UTC
Start up vte (app.vala), start typing characters at the shell prompt. Very rarely, you'll see a significant leg in those characters being echoed back in your brand new vte, and just after a few keypresses this leg becomes even bigger. Type more random characters, or execute commands such as "ls" or "date". The display sometimes only updates a few seconds later, sometimes doesn't update at all. Certain actions, like focus in/out, window resize etc. cause the contents to be correctly repainted immediately. Certain other actions, like dragging the scrollbar, highlighting a region with mouse don't repair the screen (and the mouse highlight itself is also not visible until a focus out). The value printed by a blindly executed "date" command reveals that the keyboard input is processed correctly immediately, it's the display that's not properly refreshed. Sometimes it's in a state that couldn't happen normally, like half-painted cells or so. If a vte is "born sick" this way, it stays in this mode forever, I couldn't find a way to "heal" it, "reset" didn't help. If a vte is born healthy, it seems to stay that way. I remember seeing this behavior in g-t too, but always in the very first window, never in a window/tab opened later. I immediately quit and restarted. Next time I'll try what happens if I open more tabs. I can't remember when this started to happen, probably a few weeks or maybe a month ago, but I'm really not sure. Reproducibility: very poor, 0 - 5% depending on my computer's mood.
I could reproduce with g-t. If a window is faulty, all its tabs are faulty, but newly opened windows are correct. Dragging the tabs between windows heal or break them, it's always the window that matters. The faulty window even has update problems with its notebook tabs. I don't have too much clue right now. Can this be a bug in vte (or some lib used by vte)? Or compiz/unity? What else?
Could be a gtk or WM problem. Maybe also the cause of the blinking/non-blinking cursor, or the hiding mouse pointer ?
(In reply to comment #2) > Maybe also the cause of the blinking/non-blinking cursor, or the hiding mouse pointer ? Could easily be. If only any of them were more easily reproducible...
s/leg/lag :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761671 is apparently the same.
I've just faced this with the st (suckless) terminal emulator, so it's probably an X Window bug. Seems to be related to bug 735101 too.
(In reply to Egmont Koblinger from comment #5) > I've just faced this with the st (suckless) terminal emulator, so it's > probably an X Window bug. Seems to be related to bug 735101 too. Shall we mark this as NOTGNOME then?
I haven't faced this bug in a while, probably not since upgrading to Vivid (April this year). Closing. Probably was NOTGNOME anyways.