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.
Hmm, doesn't reproduce here with 3.8, and I don't see any upstream bug about it
(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.
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!
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).
(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.
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.
(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.
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.
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.
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.
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.
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.
I can reproduce with certain window managers (unity, compiz, kde) and not with others (gnome-shell, metacity, icewm, fvwm, windowmaker).
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.
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.
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.
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.
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.
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.
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.
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.
Bug is still visible with gnome-terminal-3.14.2-2.fc21.x86_64.
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
(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
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.
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.
I still see this with: gnome-terminal-3.16.2-2.fc22.x86_64 vte291-0.40.2-1.fc22.x86_64
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.
Upstream fix is at https://bugzilla.gnome.org/show_bug.cgi?id=677329#c39, and was released in Gtk+ 3.18.9.
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.