Bug 947847 - gnome-terminal: does not switch to outline cursor when losing focus
Summary: gnome-terminal: does not switch to outline cursor when losing focus
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-terminal
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-04-03 12:20 UTC by Florian Weimer
Modified: 2016-07-19 10:08 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 10:08:44 UTC


Attachments (Terms of Use)

Description Florian Weimer 2013-04-03 12:20:05 UTC
Description of problem:

Block vs outline cursor is not a reliable indicator of keyboard focus.

Version-Release number of selected component (if applicable):

gnome-terminal-3.6.1-2.fc18.x86_64
vte3-0.34.2-3.fc18.x86_64

How reproducible:

Triggering conditions are not 

Steps to Reproduce:
1. Open two gnome-terminal windows with multiple tabs, along with other applications (Firefox, Thunderbird, Emacs).
2. Use the desktop environment for a while.
3. After some time, in one of the terminal windows, the block cursor is always displayed.
  
Actual results:

One of the gnome-terminal windows always shows the block cursor, even without the keyboard focus.

Expected results:

If the terminal window is not focused, an outline cursor is shown.

Additional info:

I have disabled cursor blinking, but apart from that, this should be a fairly standard GNOME 3 installation.

Comment 1 Matthias Clasen 2013-04-03 13:16:24 UTC
Hmm, doesn't reproduce here with 3.8, and I don't see any upstream bug about it

Comment 2 Florian Weimer 2013-06-19 05:44:15 UTC
(In reply to Matthias Clasen from comment #1)
> Hmm, doesn't reproduce here with 3.8, and I don't see any upstream bug about
> it

I still see it with a fresh install of Fedora 19.

Comment 3 Trevor Cordes 2013-08-13 05:20:09 UTC
I've been getting this bug for a long time also, perhaps started around F15?  It still happens with F19.  Note, for most people, who have cursor blinking turned on, change in Florian's comments the word "block" to "blinking".

I have a hunch it is WM and/or desktop environment dependent.  Florian, what are you using?

I am using XFCE and sawfish and have 16 virtual workspaces, plus I have 2 LCD's with xrandr and xinerama.

gnome-terminal-3.8.4-1.fc19.i686
vte-0.28.2-9.fc19.i686
sawfish-1.9.91-1.fc19.i686
xfce4-session-4.10.1-1.fc19.i686

To reproduce, open many gnome-terminal windows in many different workspaces (with many per workspace).  Maybe open some firefox too.  Use the system for a while, switching between workspaces.  Eventually (can be many hours), >1 gnome-terminal will have a blinking cursor, when only 1 should ever be blinking.  As time goes on, more windows will have blinking cursor until sometimes 5+ on the same workspace are blinking all at once!  Very distracting!

Comment 4 Trevor Cordes 2013-08-13 05:29:10 UTC
Perhaps related to old, fixed bug #73381

PS: I should also say I use click-to-focus

PPS: Once a window switches to "blinking-out-of-focus" buggy mode, it never ever stops blinking (i.e. windows never spontaneously "fix" themselves).

Comment 5 Florian Weimer 2013-08-13 06:49:32 UTC
(In reply to Trevor Cordes from comment #3)
> I have a hunch it is WM and/or desktop environment dependent.  Florian, what
> are you using?

GNOME 3, classic mode, with the cursor blinking switched off (as you noticed), but otherwise fairly standard settings, I think.

Comment 6 Trevor Cordes 2013-08-13 12:21:02 UTC
I'm surprised you're using GNOME 3, I would have sworn this problem would have been related to weird WM's or DE's.  If not due to something relatively rare, then why aren't a million people me-to'ing this bug?

How many virtual workspaces do you have and do you switch often?  (Assuming GNOME3 has VW's!!)

Do you use click-to-focus or mouse-in to focus?

1 screen or 2 (or more)?

There's got to be something weird only we are doing that limits this problem to us.  We need to find out what.

Comment 7 Florian Weimer 2013-08-13 12:25:51 UTC
(In reply to Trevor Cordes from comment #6)
> I'm surprised you're using GNOME 3, I would have sworn this problem would
> have been related to weird WM's or DE's.  If not due to something relatively
> rare, then why aren't a million people me-to'ing this bug?

The only unusual thing is that I've got an external monitor in portrait mode, and I often switch monitors while the laptop is suspended.  It does not seem to trigger this AFAICT.

You need multiple terminal windows, and you have to care about this detail.  Several folks I spoke to have noticed it, but weren't bothered by it.
 
> How many virtual workspaces do you have and do you switch often?  (Assuming
> GNOME3 has VW's!!)

I only use one workspace.  I can't rule out that I trigger workspace switches by accident.

> Do you use click-to-focus or mouse-in to focus?

Click-to-focus.  With F18, it happened to me with focus-follows-mouse, too.

> 1 screen or 2 (or more)?

Two screens.

Comment 8 Christian Persch (GNOME) 2013-08-13 13:41:26 UTC
I was seeing this too, on F19 with gnome-shell and click-to-focus (anything else is unsupported in g-t, btw!). 'Classic' mode.

What happened was that gtk_window_state_event was still being called on 'focus' in/out (so the backdrop state still changes accordingly); but *no* focus in/out events were being delivered: there were no calls to gtk_widget_event_internal with event->type == GDK_FOCUS_CHANGE, gtk_window_focus_in/out_event, vte_terminal_focus_in/out.

I'm inclined to think this is not a bug in gnome-terminal or vte, but in gtk+, or perhaps the window manager.

Comment 9 Trevor Cordes 2013-08-14 06:55:37 UTC
If it was a WM bug, why is it showing up in multiple WM's?  (Me with sawfish, Florian with whatever Gnome3 uses.)

Perhaps you're right in that it's a gtk+ bug.  The related old bug #73381 was a gtk2 bug.

Like I said, this bug was NOT present in my XFCE+sawfish setup up to about F14-F16 (might have been F13-F16, my memory is poor), then all of a sudden it showed up when I upgraded to the next Fedora.  I'm sorry I didn't record exactly which versions changed when I first saw it.  I figured it was a sawfish bug as sawfish has lots of bugs.

Comment 10 Egmont Koblinger 2014-06-04 22:18:34 UTC
I just turned on cursor blinking (I-Beam shape) and saw that in one of my terminals blinking didn't start/stop on focus in/out.  I guess it goes together with the block/outline issue, at least ChPe's comment suggests this.  I'll use blinking block cursor for a while, hoping the bug appears again.

Also, if that's the case then I assume all the tabs inside a window will misbehave, drag-n-dropping tabs between windows should fix/break the cursor according to the window's state.

I'm using Unity, the default of Ubuntu 14.04, all stock packages except for vte/gnome-terminal which are from git master.

Gtk+ bug is my best bet, too.

Comment 11 Egmont Koblinger 2014-06-05 10:41:37 UTC
It happened again.  The behavior is indeed what I expected in the previous comment:

The faulty behavior is tied to a window.  All new tabs inside that window are buggy.  Drag-n-drop a tab out of this to another window and it'll behave okay.  Dnd a tab from another window to this one and it'll be faulty.

The cursor always stays a block, never becomes outlined.  It starts blinking on keypress or when switching to that tab, and stops blinking after the timeout (as expected), but doesn't start/stop blinking on focus in/out.

This behavior perfectly aligns with chpe's findings in comment 8.

Comment 12 Egmont Koblinger 2014-06-10 18:32:45 UTC
Here's how to reproduce this bug with (almost) 100% reliability:

- Open two windows: one gnome-terminal and one xterm. They may or may not overlap.
- Make xterm have the focus. (If they overlap, xterm is visible there.)
- Move the mouse so that it's over the g-t window (it might be over the overlapping part where xterm is visible, or over the g-t-only area).
- Exit xterm by pressing Ctrl+D.
- Voilà! g-t window becomes broken.

Comment 13 Egmont Koblinger 2014-06-10 18:54:48 UTC
I can reproduce with certain window managers (unity, compiz, kde) and not with others (gnome-shell, metacity, icewm, fvwm, windowmaker).

Comment 14 Egmont Koblinger 2014-06-10 20:03:52 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=677329 seems to be relevant.

With the patch from comment 4 the bug no longer arises, although (from the very start) mouse enter events are mistakenly handled as focus in.

Comment 15 Fedora End Of Life 2015-01-09 17:50:50 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Trevor Cordes 2015-01-10 10:02:17 UTC
This was never fixed in F19, but since upgrading to F21 (about a week ago) I have not seen this happen even once.  I think this was fixed upstream?  After another week of the abuse I put on terminals I'd feel confident calling this one fixed and then it can be closed.  Also, no one has commented on it for a long while so maybe everyone else is experiencing the same as I?

Thanks for fixing this guys! it was driving me crazy.

Comment 17 Egmont Koblinger 2015-01-10 10:21:36 UTC
It's still buggy under Ubuntu Utopic + Unity WM.  According to comment 13, the behavior depends on the WM, and Fedora defaults to one where this bug doesn't occur, and probably you're using the same.  I'm pretty sure the bug is still there in F21 too with some WMs.

Comment 18 Trevor Cordes 2015-01-10 11:52:12 UTC
I had this bug *all the time* in F19 up until I upgraded to F21 last week.  It would happen within a few hours of normal desktop use -- every time, always.  It has not happened in almost a week of F21 use, not once.

I am using the exact same wm (sawfish) as I was under F19, just the newest (Fedora rpm'd) version.  (I use nothing that is the default of anything :-) )

It could be I have to give it more time, so I will report back in 1-2 weeks.

If this doesn't happen anymore in F21 for my case anyway (sawfish + XFCE) it is fixed.  If I spoke too soon and it pops up on my box again, I'll report back.  I usually have >100 terminals open on 16 workspaces open and so if bugs like this are around I usually see them.

Comment 19 Trevor Cordes 2015-01-10 12:24:10 UTC
Sorry, spoke too soon.  During my open/kill 50 terminal testing for bug 1176603 I had this bug reappear.  It is slightly different now though, as sometimes instead of 2+ cursors blinking, a "broken" window will have its cursor stay a solid block.  If I do a few mouse/workspace events it will eventually get into a 2+ blinking state.  So this bug does persist in F21 (with sawfish + xfce).  Sorry for the false alarm, I had gotten my hopes up.

Comment 20 Egmont Koblinger 2015-01-10 12:30:35 UTC
Reminder: comment 14 links to the underlying cause -- the bug is not in gnome-terminal itself, it's affected by a bug in X/WM/Gtk+ who knows what.  The underlying story is quite complicated, at least I failed to understand what happens and what should happen.

Comment 21 Fedora End Of Life 2015-02-17 14:56:01 UTC
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 22 Florian Weimer 2015-02-17 15:09:39 UTC
Bug is still visible with gnome-terminal-3.14.2-2.fc21.x86_64.

Comment 23 Trevor Cordes 2015-04-12 05:55:59 UTC
I just had this happen for the first time in many weeks (months?).  This used to happen all the time for me but some update or other made it go away (mostly).

This time it's very strange.  I'm playing with the broken window(s) right now as I document it:

W1=window1
W2=window2

W1 works fine
W2 is broken: does this:

- W2 shows solid cursor (not outline) when not in focus (bug)
- type something in W2, cursor starts blinking (good)
- wait 10.5s with W2 in focus, cursor goes solid, stops blinking (goes through 10-11 cycles with my settings)! (bug, never seen this before)
- type something in W2 and immediately focus W1, now cursor is blinking in both W1+W2 simultaneously (bug, that's what always used to happen to me)
- W2 will eventually go all-solid and stay that way while unfocused (10-12 cycles).  If I wait ~8 cycles before changing focus from W2 to W1 then W2 will go all-solid sooner after the click, like 3-4 cycles.  i.e., the cycle count starts from the keypress in W2, regardless of when I click into W1.
- In fact, if I rapidly cycle W1/W2 a ton, W2 will still go into all-solid after its normal 10-12 cycles.

I'm not sure what got it in this state, but I was doing a ton of work having this buggy W2 launch mplayer videos then quit them rapidly (as in 3-10s each video), maybe a few hundred times.  Not sure if that's related.  There is a W3 on the same xineramascreen that is also broken in exactly the same way.

I'm using Ggnome-terminal-3.14.2-2.fc21.x86_64 with DK_CORE_DEVICE_EVENTS=1 while trying to debug another bug #1176603

Comment 24 Egmont Koblinger 2015-04-12 21:47:36 UTC
(In reply to Trevor Cordes from comment #23)

> - wait 10.5s with W2 in focus, cursor goes solid, stops blinking (goes
> through 10-11 cycles with my settings)! (bug, never seen this before)

This is not a bug, this is intentional, it's been so since 2008. See cursor-blink-timeout in your dconf settings, and cursor_blink_timeout in vte's source. Blinking, by intent, should start at focus in and at keypress, and should stop at focus out or after cursor-blink-timeout (by default 10) seconds of keyboard inactivity.

So I believe it's still nothing more and nothing less than the single underlying bug that sometimes a window stops receiving focus in/out events. This one's fully reproducible, see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=677329#c30

Comment 25 Trevor Cordes 2015-04-13 20:33:57 UTC
Oh, you're right!  Evil evil!  How do I disable blink-timeout.  Evil!  I'll be hacking around in dconf now...

But, it's still a bug in my scenario above because it's still blinking *after* losing focus :-)  So you're right, it's all the same thing.  Maybe I never noticed the blink-stop before because I was using the ancient Fedora 19 vte for so long and just switched a couple of months back to something modern.

Comment 26 Fedora End Of Life 2015-11-04 12:41:41 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 27 Florian Weimer 2015-11-04 12:52:25 UTC
I still see this with:

gnome-terminal-3.16.2-2.fc22.x86_64
vte291-0.40.2-1.fc22.x86_64

Comment 28 Mark B 2015-12-13 12:57:33 UTC
I'm on Arch with gnome-terminal 3.18.2-1 with vte3 0.42.1-1, gnome-shell 3.18.3-1 and see this exact bug.

Comment 29 Egmont Koblinger 2016-03-15 03:29:26 UTC
Upstream fix is at https://bugzilla.gnome.org/show_bug.cgi?id=677329#c39, and was released in Gtk+ 3.18.9.

Comment 30 Fedora End Of Life 2016-07-19 10:08:44 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.