After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 730763 - Sometimes vte is born sick, doesn't properly update display
Sometimes vte is born sick, doesn't properly update display
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
0.37.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-26 13:06 UTC by Egmont Koblinger
Modified: 2015-09-17 22:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2014-05-26 13:06:17 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.
Comment 1 Egmont Koblinger 2014-05-26 13:26:30 UTC
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?
Comment 2 Christian Persch 2014-06-10 10:40:54 UTC
Could be a gtk or WM problem. Maybe also the cause of the blinking/non-blinking cursor, or the hiding mouse pointer ?
Comment 3 Egmont Koblinger 2014-06-10 10:50:54 UTC
(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...
Comment 4 Egmont Koblinger 2014-11-01 14:38:24 UTC
s/leg/lag :)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761671 is apparently the same.
Comment 5 Egmont Koblinger 2015-02-20 15:56:56 UTC
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.
Comment 6 Debarshi Ray 2015-05-26 16:54:54 UTC
(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?
Comment 7 Egmont Koblinger 2015-09-17 22:07:34 UTC
I haven't faced this bug in a while, probably not since upgrading to Vivid (April this year). Closing. Probably was NOTGNOME anyways.