Yes. It's so that the mouse cursor's not in the way.

I have upgraded to 3.12 and I find this new behavior extremely annoying. I usually have terminal fullscreen and then I move the mouse and I have no clue where the pointer is.


I'd be ok with hiding the pointer, but as soon as I move the mouse it should reappear

(In reply to comment #2)
> I'd be ok with hiding the pointer, but as soon as I move the mouse it should
> reappear

so after discussing on irc, it seems that what this is indeed the intended behavior, which is ok. However it seems there is a bug that makes it not reappear under some conditions. Other people on irc reported the same, so it is not an isolated case.

Maybe the bug should be reopened to track this?

I am running into this regularly.  Let me know if you need more information and I will be happy to provide the input.  Running GNOME 3.12 off the Copr repository in Fedora 20.

Just to add another data point, I also see this bug intermittently. For me at least, I've found that a single click anywhere in the terminal will restore the mouse to visibility (not a solution, just a decent workaround).

Hiding the cursor when a non-modifier key is pressed and restoring it when a button is clicked or the mouse is moved is not new. The code in question is _vte_terminal_set_pointer_visible in vte and it has been around for more than half a decade now (according to Git).

My guess is that something else broke here. We need to find out what.

Since recently the mouse cursor is sometimes gone and doesn't come back until you switch applications. Moving the mouse doesn't make it reappear.

(In reply to comment #7)
> doesn't come back until
> you switch applications. Moving the mouse doesn't make it reappear.

Yes that is the thing. It supposed to reappear on moving the mouse, but apparently it only reappears if you click it.

Unfortunately I can not reproduce this nor can chpe as far as I know. So would anyone of you be willing to poke at the usage of _vte_terminal_set_pointer_visible in src/vte.c ? The code is in the vte module, not gnome-terminal.

Created attachment 276710 [details] [review]
clear last_mouse_button on focus out

This patch fixes the problem as I was seeing it.

It looks like the mouse release event is never received when opening a terminal from the context menu.

Makes sense. Let's try this on master for a while to see if it breaks anything, then this can go to 0-36 too (no releases planned there, though).

Comment on attachment 276710 [details] [review]
clear last_mouse_button on focus out

Pushed to master

Thanks a lot, Colin! :)

*** Bug 737163 has been marked as a duplicate of this bug. ***

I am still hearing about this bug from Fedora 22 / GNOME 3.16 users. Reopening.

*** Bug 750186 has been marked as a duplicate of this bug. ***

This happens for me on Arch with gnome-shell 3.16.2-2 in gnome-terminal 3.16.2-1 using a touchpad. Cursor remains hidden even when I move it. I have to click on something in same or another terminal window until it appears, or move across the window of another app.

This is also happening for me on Arch, gnome-terminal 3.16.2. It doesn't seem to occur on all windows, only happens on the one that I have maximised with irssi running in.

I see this periodically in both F22 and F23 where one of my terminals stops turning the cursor back on when the mouse moves.

What I've found is that when it happens running /usr/bin/reset to reset the terminal state in that window will fix it, temporarily at least.

It's 6 months later to my report just above. Nowadays Arch has moved from 3.16 to gnome-shell 3.18.3-1 with gnome-terminal 3.18.2-1 but this annoying bug still remains as described here.

Uugh.. Can we drop this new "feature" yet? It makes gnome terminal almost dangerous to use while working on critical infrastructure servers via ssh. Mouse cursor disappearing and not easily reappearing can lead to stray clicks and keypresses attempting to reactivate it.

I see this bug in Arch, Ubuntu, and Fedora

Using Gnome-terminal with the mouse disappearing and not reappearing until you click is very dangerous.  Clicking the mouse without knowing what you are clicking on has caused problems for me.

Hopefully the powers that be will disable this hiding of the mouse until this bug of the mouse not reappearing until you perform a blind click is fixed.

I prefer to know where my mouse is at all times.  I could deal with it being hid until the mouse is moved, but the cure bug of a blind click requirement is too much of a security issue.  I have to use an alternative terminal until this bug is fixed (or announced as fixed).

I'll gladly participate in testing the fixed version in controlled non-critical environments, and comment if it's fixed.

-- L. James

-- 
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames

This is not a gnome-terminal/vte bug. vte will re-show the mouse pointer as soon as it receives a motion-notify event. That it doesn't do so means that somehow it's not receiving the motion event, which means the problem is on a different layer, either in gtk+, the window manager (gnome-shell) or the X server.

Can we close this as NOTGNOME then?

Bug 759387 tracks a feature request to disable autohide entirely which should be a good enough workaround.

This bug only appears when running gnome-terminal.  There are many applications that will hide the cursor (including screen savers) until the mouse is moved.

If there is something happening where a single application isn't receiving a mouse movement notification, I would hope the developers would be interested in addressing this issue.

Reading the other comments it's happening across quiet a number of Linux flavors and installations.

Thanks for pointing us to the feature request for a workaround while Gnome-Terminal is currently missing the restore cursor functionality in many of our environments.

-- L. James

-- 
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames

Not really NOTGNOME since it might be gtk+ or gnome-shell, but I think it's likely the same cause as missing focus events (bug 677329).

I don't really see how resetting the terminal state would cause focus events to suddenly start appearing though? and in my experience resetting the terminal state always fixes a terminal where this has started happening...

In vte_terminal_motion_notify() we only turn on the cursor if (terminal->pvt->mouse_pressed_buttons != 0). I see no other place where this could go wrong. I think mouse_pressed_buttons gets stuck at a nonzero value, that is, we miss one of the release events.

This would also explain why a click or a focus out or a /usr/bin/reset stops this buggy behavior - at least for a while.

In the mean time I'm wondering why enabling the cursor is guarded by this condition. This results in weird behavior if you press a key while selecting; you'll no longer see the mouse for the duration of the selection.

Similar: right click in mc to toggle a file, press a key, move the mouse vertically to toggle more files. The cursor is not visible.

Changing this might solve the current bug (without actually revealing the underlying cause).

Created attachment 317301 [details] [review]
Always show mouse on motion

Could you please try if this patch fixes the problem?

... although, if this patch works, the next problem will be that URLs won't be highlighted on mouseover whenever the mouse would have remained hidden without this patch.

Nicely phrased duplicate report: https://bugzilla.redhat.com/show_bug.cgi?id=1293172

Not reproducible here using the steps from the bug in comment 30, which is another hint that the problem not in vte nor gtk but the WM or X server.

The issue is more difficult to reproduce than previously thought.  Something gets gnome-terminal into a running state where the steps on the bug in comment 30 work.  It seems to take a couple days for gnome-terminal to get into this state.  The problem does not follow new terminal windows, but does follow new tabs within a gnome-terminal that is already experiencing the problem.

I've used GDB in the past, I just installed gnome-terminal-debuginfo.  Once I get a terminal into a broken state I can attach GDB to the process and inspect some variables, though I'm not sure where to start.  If someone wants to give me some print commands or a few GDB scripts I can run them and post the results here.  I can run the commands in all 3 "broken" states (let me know if I'm missing something):
1) after right click but before typing - cursor is visible but will be hidden
2) after right click and typing - cursor "lost".
3) after switching tabs to restore mouse.  Right-clicking and typing again will hide the cursor again.

I'm willing to try patching my gnome-terminal and/or vte to add debug logging if that will help.  Obviously patching will require me to start a new terminal, and it will take a few days to reproduce the issue again.

I do not think it is worth while to try patches that might fix the problem as we have not yet determined how to get the terminal into the broken state in the first place.

I may be seeing the this same issue, after upgrading to FC23.

The cursor disappears in the active area of the gnome-terminal, until I click on the window and it gets focus.

This does not happen in other terminal emulators running in my environment (cinnamon desktop), for example Terminology, nor has it happened in any other program.

This bug does make gnome-terminal less useful compared to the several other terminal window programs that are available for the desktop.

Come on. Let's disable this "feature".   No one is 'annoyed' that their cursor doesn't disappear and everyone is annoyed that their cursor doesn't reappear.

Still no evidence of this being a bug in gnome-terminal.

The first way I read that is that its a feature not a bug.

Its hard to see how someone would intend that behavior.  It seems more likely that someone neglected to get the mouse events when it passes over the exposed part of the window.

That would make it a mistaken design or an implementation error (i.e., a bug).

Another way to read your comment is that you feel that the program was designed and coded correctly, and that the problem is somewhere else.

To that we note that lots of other programs running in the same environment, do not exhibit the errant behavior.

If the maintainers' feel there is nothing to fix, that's okay, we the user community are free to use another console terminal program.

The evidence of the bug is in the number of users that is being affected by it.  There's something wrong where Gnome-terminal hides the mouse in many or our environments, but don't bring it back without clicking on the window that hid it.

It's been an annoyance with me for three Ubuntu versions.  I didn't report it because I figured, either the problem was temporary and go away, or be fixed my next Ubuntu install of which I do at least once a year.  I've done twice  year since the bug because I kept thinking it would get resolved.

I finally resolved the issue by changing terminal emulators.  I prefer that is my distro's default installation, and have still loaded gnome-terminal once a month to see if the bug still exist.

It's unfortunate that I can't tell what is going to trigger the bug, it always takes hours or days before it happens, but it happens.  The mouse hides and doesn't come back until you click on the particular window.  Working in a three monitor environment with lots of windows opened takes a lot of work to figure out where to click.

The problem only happens with gnome-terminal.  All the other applications that hid the mouse performs correctly (other programs such as xplane and video players).

Since the bug happens to lots of people (not bringing the cursor back when moving the mouse) the developers should provide relief by giving the option of not hiding the mouse.

I'm glad that, at least, this problem is revisited.

(In reply to M C Nelson from comment #36)
> The first way I read that is that its a feature not a bug.
> 
> Its hard to see how someone would intend that behavior.  It seems more
> likely that someone neglected to get the mouse events when it passes over
> the exposed part of the window.

I think what M C was trying to say is that the feature of suppressing the mouse cursor from being displayed while typing is probably not worth the number of bugs that have come up because of it.

The suggestion being made was to drop the feature and simply never have the mouse cursor be hidden; then there would be no bugs with it failing to come back.

Ultimately, it's a value judgement: is keeping this feature important enough to justify spending time to fix bugs when it doesn't behave properly?

(In reply to Stephen Gallagher from comment #38)
>
> I think what M C was trying to say is that the feature of suppressing the
> mouse cursor from being displayed while typing is probably not worth the
> number of bugs that have come up because of it.
> 

No, I had only noticed that the cursor does not appear when the mouse moves over the window.  So, I thought it was just an error in design or coding.  Now I see that it actually does appear after a cold boot and then goes away.  That's a bug, no two ways about it.

That kind of behavior can be produced by an overrun or pointer error, so it really does need to be found and fixed.

If the maintainer doesn't want to acknowledge the problem, then the program should be scrapped or banned until it gets resolved.

What is risking getting banned is some accounts here, if their owners don't stop polluting this bug with uninformed and irrelevant opinions instead of contributing facts that lead to finding and fixing this issue.

If you want to contribute to this bug being fixed, then you should find out why it happens, not advocate for adding prefs or removing the feature.

Let me summarise what this bug report is about: vte hides the mouse pointer when it is over the terminal, and re-shows the mouse pointer when the mouse is moved. vte has done so for a long time, without any problems. Recently, it appears that vte is sometimes not re-showing the mouse pointer on mouse motion. The reason for this is unknown, and in need to be debugged. Most likely, there is some bug in another component (gtk, the WM, or X server) that causes vte not to receive these motion events under some circumstances.

> [...]
> that causes vte not to receive these motion events under some circumstances.

@ChPe Your _guess_ is that it does not receive mouse events, my _guess_ is that it does not receive a button release event. Could be either one, or even something else.

@all What we'd need is somebody who can reproduce the problem _and_ perform meaningful debugging. Alas, apparently there's no such person at this moment.

(In reply to Christian Persch from comment #40)
> What is risking getting banned is some accounts here, if their owners don't
> stop polluting this bug with uninformed and irrelevant opinions instead of
> contributing facts that lead to finding and fixing this issue.

Wow... just wow. We're having a meaningful conversation about an extremely buggy feature and you start threatening to ban users in response.

> If you want to contribute to this bug being fixed, then you should find out
> why it happens, not advocate for adding prefs or removing the feature.

Patch attached to fix the issue. Anything that is seriously flawed / broken shouldn't be forced on users until it is functional. Why wasn't cursor hiding kept in a branch and only merged when ready? Using multiple gnome-terminal windows for any amount of time longer than 5 minutes for real work (vim, screen, top, etc) triggers this bug. I can reproduce it on three different distributions with a mix of graphics hardware. (Intel, Nvidia, AMD)

> Let me summarise what this bug report is about: vte hides the mouse pointer
> when it is over the terminal, and re-shows the mouse pointer when the mouse
> is moved.

No, the bug report is about vte hiding the mouse pointer and not re-showing it until you use your invisible mouse cursor to "find" the terminal and click on it to trigger re-appearance.  This has been stated multiple times verbatim. (see Description, comment 2, comment 5, comment 6, comment 7, comment 8, etc, etc)

> vte has done so for a long time, without any problems.

This is incorrect. Look at the age of this bug. It has been going on quite some time. Because no-one reported it until 2014 doesn't mean it hasn't been occurring for longer. Most likely assumed Gnome would fix it... when they didn't people started looking into it and reporting it. I'm pretty sure i've seen it since at least 3.10

Created attachment 319222 [details] [review]
Patch to disable auto-hide until it is stable / functional.

(In reply to Egmont Koblinger from comment #41)
> > [...]
> > that causes vte not to receive these motion events under some circumstances.
> @all What we'd need is somebody who can reproduce the problem _and_ perform
> meaningful debugging. Alas, apparently there's no such person at this moment.

What debugging needs to happen? Multiple people has said that they are willing to debug but have been given no information on what to do to help.

(In reply to Alexander von Gluck IV from comment #42)

> Patch attached to fix the issue.

Your patch does not _fix_ the issue per se, it works around the issue by changing the behavior.

> Why wasn't cursor hiding kept in a branch and only merged when ready?

You wanna help develop vte? And would you maintain a branch for any tiny new feature for 10+ years until it proves rock solid?

> I'm pretty sure i've seen it since at least 3.10

3.10, wow, that was like 2 years ago! Guess what, mouse autohide was introduced in 2002.

We're 99.9% positive that the bug is somewhere outside vte. That being said, any help tracking down the problem is appreciated! Flaming is not.

(In reply to Alexander von Gluck IV from comment #44)

> What debugging needs to happen? Multiple people has said that they are
> willing to debug but have been given no information on what to do to help.

To begin with, I asked a question in comments 28-29 and noone responded yet. So much about the willingness of those multiple people...

This *is* an attempt to help you debug it, and it is based on experience.

  "We're 99.9% positive that the bug is somewhere outside vte."

If it is outside of vte, then (a) there should be other programs that exhibit the same bug, or (b) vte is using some api that no other program is using

So, we have two questions:

A) Can you tell us what other programs exhibit this bug?

Or

B) Can you tell us what api this program is using that no other program is using?

If the answers to these two questions are "there are none", then it would seem that you have to admit the possibility that the bug is in gnome-terminal.

f so, then there are at least two broad categories to think about:

(a) that gnome terminal is not interacting with the api correctly, or

(b) that gnome-terminal is polluting something, possibly in the api, c.f. a pointer error or overrun.

That the behavior occurs after some threshold is reached is evidence for the latter, though not conclusive.

There are more exotic possibilities of course, but lets stay with simple for the moment.

That brings us to three more questions:

1) Does the threshold behavior bring something to mind from your knowledge of the code?

2) Have you tried running it with electric fence?

3) Have you tried instrumenting *all* of the data structures associated with the mouse being displayed?

As to my previous comment,  if there is a possibility that this is an overrun, then for a widely used program such as gnome-terminal, it becomes very important to find it and fix it quickly because it might effect security or availability in some situations.

> This *is* an attempt to help you debug it

Again: we (Christian and me) can _not_ reproduce the bug. Hence we cannot debug it.

Apparently you can reproduce it and you have ideas how to debug. So instead of writing long philosophical essays, could you, by any chance, please contribute to vte by trying to analyze what is actually happening?

> and it is based on experience.

I've no clue about your experiences, my experiences give me a gut feeling that you're completely on the wrong track with your reasoning. (a) and (b) are not the only possible reasons. Anyway, please refrain from far-fetched ideas, please contribute concrete meaningful pieces of informations!

(In reply to Christian Persch from comment #25)

> I think it's likely the same cause as missing focus events (bug 677329).

Okay, I finally managed to reproduce the bug. I just had to put the puzzle pieces together.

Christian, you were right, it's apparently the same (or very similar) reason as the infamous focus-out bug. That is, this mouse hiding issue occurs in exactly those windows where the focus events are missing (which is seen by the cursor remaining a blinking solid rectangle rather than a non-blinking outlined rectangle on focus out).

The steps to get to this state for me are still the ones described in bug 677329 comment 24.

@Christian: Can you reproduce it following these steps? First follow these steps to get a window with missing focus events, then right-click to open its context menu and close it by any means.

Comment 28's patch indeed fixes the problem, but it indeed introduces comment 29's regression (and for some reason clicking doesn't fix it either).

If I enable mouse reporting in the terminal via escape sequences, I can see all further events (motion, click, release) as expected. So probably it's only the release of the right mouse click that opens the menu that goes missing. I haven't started debugging it yet.

We should really get that goddamn focus bug fixed once and for all!!!

I see the bug without xterm involved and in my environment (fc23, cinnamon), it seems intermittent. And again, I have not seen any program other that gnome-terminal that does it. Can you think of some reason why only gnome-terminal has this problem?

If you want me to run some tests, please send instructions for retrieving and building the code and of course for whatever tests you want me to run.

(In reply to Egmont Koblinger from comment #48)
> > This *is* an attempt to help you debug it
> 
> Again: we (Christian and me) can _not_ reproduce the bug. Hence we cannot
> debug it.
> 
> Apparently you can reproduce it and you have ideas how to debug. So instead
> of writing long philosophical essays, could you, by any chance, please
> contribute to vte by trying to analyze what is actually happening?
> 
> > and it is based on experience.
> 
> I've no clue about your experiences, my experiences give me a gut feeling
> that you're completely on the wrong track with your reasoning. (a) and (b)
> are not the only possible reasons. Anyway, please refrain from far-fetched
> ideas, please contribute concrete meaningful pieces of informations!

well it is your code, you know it best.  but see my previous post (50)

p/s those instructions don't reproduce the bug for me.

Configure errors:

  No package 'vte-2.91' found
  No package 'uuid' found

Both packages are installed.

Bug 677329 comment 24 allows me to reproduce the issue every time.  Previously I did not use xterm, I am still unsure exactly what I did to get the terminal into a state where right-click + typing would permanently hide the cursor.  It does not seem to matter how I exit xterm: Ctrl-D; alt-space then C, or typing 'exit' into the terminal.  As long as your mouse is over gnome-terminal when you quit xterm.  Also the mouse has to be over the actual terminal space, not menu or window borders.

The patch in comment 28 fixes the cursor hiding, but does not fix the URL highlighting.  The URL highlighting can still be worked around by the 'reset' command or by switching tabs within the current gnome-terminal window.  When you right-click a URL to cause the bug, your mouse cursor will temporarily become stuck as the hand (until you type any key).  Unsure if that is helpful.

Now that I have a reliable way to reproduce the issue I can do any testing that is requested.

Nope, doesn't do it on my system

so far, it appears randomly, and until this started happening a lot, i pretty much only used gnome-terminal.

@all Please let us know the following:

- Make sure you have at least one of these two: The terminal cursor shape is a rectangle (this is the default; it's a gnome-terminal profile setting), or the terminal cursor is blinking (it's a global Gnome setting that the cursor blinks). Note that whenever you leave gnome-terminal and focus another window, the cursor immediately stops blinking and/or becomes an outlined rectangle, at least one of these two should be visible.

- Keep using gnome-terminal as you used to use it. When the disappearing mouse pointer kicks in, type a letter (to start blinking) and then focus another window and check the terminal cursor. Does it stop blinking and becomes an outlined rectangle as expected, or does it keep blinking and/or remains a filled rectangle as if you did not switch away from that window?

(In reply to Egmont Koblinger from comment #49)
> Christian, you were right, it's apparently the same (or very similar) reason
> as the infamous focus-out bug. That is, this mouse hiding issue occurs in
> exactly those windows where the focus events are missing (which is seen by
> the cursor remaining a blinking solid rectangle rather than a non-blinking
> outlined rectangle on focus out).
> 
> The steps to get to this state for me are still the ones described in bug
> 677329 comment 24.
> 
> @Christian: Can you reproduce it following these steps? First follow these
> steps to get a window with missing focus events, then right-click to open
> its context menu and close it by any means.

Brilliant! I can predictably reproduce the bug with these steps.

(In reply to Debarshi Ray from comment #58)
> (In reply to Egmont Koblinger from comment #49)
> > Christian, you were right, it's apparently the same (or very similar) reason
> > as the infamous focus-out bug. That is, this mouse hiding issue occurs in
> > exactly those windows where the focus events are missing (which is seen by
> > the cursor remaining a blinking solid rectangle rather than a non-blinking
> > outlined rectangle on focus out).
> > 
> > The steps to get to this state for me are still the ones described in bug
> > 677329 comment 24.
> > 
> > @Christian: Can you reproduce it following these steps? First follow these
> > steps to get a window with missing focus events, then right-click to open
> > its context menu and close it by any means.
> 
> Brilliant! I can predictably reproduce the bug with these steps.

I can also reproduce using the vte-2.91 test application.

The steps from bug 677329 comment 24 do _not_ reproduce here, both in gnome-terminal and the vte-2.91 test app.

my (In reply to Egmont Koblinger from comment #57)
> @all Please let us know the following:
> 
> - Make sure you have at least one of these two: The terminal cursor shape is
> a rectangle (this is the default; it's a gnome-terminal profile setting), or

That still doesn't do it.

The mouse pointer seems to disappear randomly,  no connection to xterm or the state of the window so far.

(In reply to Christian Persch from comment #60)
> The steps from bug 677329 comment 24 do _not_ reproduce here, both in
> gnome-terminal and the vte-2.91 test app.

Please try with one of the WMs listed at https://bugzilla.redhat.com/show_bug.cgi?id=947847#c13

(In reply to Egmont Koblinger from comment #57)
> @all Please let us know the following:
> 
> - Make sure you have at least one of these two: The terminal cursor shape is
> a rectangle (this is the default; it's a gnome-terminal profile setting), or
> the terminal cursor is blinking (it's a global Gnome setting that the cursor
> blinks). Note that whenever you leave gnome-terminal and focus another
> window, the cursor immediately stops blinking and/or becomes an outlined
> rectangle, at least one of these two should be visible.
> 
> - Keep using gnome-terminal as you used to use it. When the disappearing
> mouse pointer kicks in, type a letter (to start blinking) and then focus
> another window and check the terminal cursor. Does it stop blinking and
> becomes an outlined rectangle as expected, or does it keep blinking and/or
> remains a filled rectangle as if you did not switch away from that window?

I can confirm all of this under fc23 w/ cinnamon wm.  Terminal starts with filled in blinking rectangle cursor, goes outline + non-blinking when terminal is unfocused.  Once the disappearing mouse pointer bug is reproduced the cursor becomes stuck on the blinking filled in rectangle.  As with everything else in this bug the cursor is fixed by running 'reset' in that terminal or switching gnome-terminal tabs back and forth.

When the right-click menu is invoked, we always get button_press and _never_ get button_release -- neither during normal operation, nor during the buggy behavior.

Hence, as far as the widget_button_press() and widget_button_release() methods are concerned, m_mouse_pressed_buttons would get stuck at containing the 3rd mouse button.

Which, in turn, would get widget_motion_notify() not to make the pointer visible, leading to the buggy behavior.

Under normal operation there's another step: the widget_focus_out() method clears m_mouse_pressed_buttons. It kinda takes care of handling that "release" event that is _always_ missing.

Under buggy operation, the widget_focus_out() method is not called, hence m_mouse_pressed_buttons remains stuck believing that the 3rd button is pressed.

So... is there an easy workaround (other than fixing the actual focus-out bug)? At this moment I'm unsure.

Is there a way to poll the set of pressed buttons on demand, rather than doing our own housekeeping?

The problem is that vte has no knowledge about whether the app is going to open a menu or do something else, and hence it doesn't know whether to expect a counterpart "release" event or not.

There are two variables: m_mouse_handled_buttons and m_mouse_pressed_buttons. I'm wondering if we really need the second one or we could only go with the first only. After all, if an app wasn't interested in a mouse event, why should vte be? (I'm not sure if it's a good idea, I might be missing something.)

Anyway, even if we didn't have the focus-out bug, the current design relying on the focus-out event to reset the bitmap is IMHO be quite ugly.

Should this bug really be classified as "normal minor" if the workaround is to click randomly? Clicking randomly has undesirable, unknown (depending on what window it's in) side effects. At the least, click can change the cursor location, at worst, cause things to become unselected/selected, move things, delete things.

I don't think playing with the Importance field would get us to a solution any sooner. Finding someone who can actually work on the aforementioned focus bug 677329 (or a workaround in vte) would.

So i'll ask again.. if we don't have a solid solution, how about someone (hell i'll do it, it's like a 5 line change) adding some hidden config option to disable the cursor hiding? As Steve said, random clicking really is a bad scenario.

See bug 759387.

Could someone please point us to source that (a) exhibits the errant behavior and (b) can be compiled on an x64 fc23 system at the rev levels of the stable and update repositories?

Thank you

IMO any effort spent on trying to fix or work around this bug should instead be spent on fixing (or getting someone to fix) the underlying bug 677329.

Even so, I still need something that exhibits (or elicits) the behavior.

In an earlier comment you stated you could reproduce the bug. Did I get that wrong? What else do you need? Read carefully through this entire bug as well as all the referenced bugs. That's all the information we have right now.

The bug on my machine, is intermittent.

What I would like, is source code that I can compile in my environment.

P/S I have read through this and the referenced bugs.

(In reply to M C Nelson from comment #74)
> The bug on my machine, is intermittent.
> 
> What I would like, is source code that I can compile in my environment.

Read wiki.gnome.org/Newcomers to build and provide patches for Gnome apps (like gnome-terminal)

Okay, thank you, that looks promising.

(In reply to Egmont Koblinger from comment #57)
> @all Please let us know the following:
> 
> - Make sure you have at least one of these two: The terminal cursor shape is
> a rectangle (this is the default; it's a gnome-terminal profile setting), or
> the terminal cursor is blinking (it's a global Gnome setting that the cursor
> blinks). Note that whenever you leave gnome-terminal and focus another
> window, the cursor immediately stops blinking and/or becomes an outlined
> rectangle, at least one of these two should be visible.
> 
> - Keep using gnome-terminal as you used to use it. When the disappearing
> mouse pointer kicks in, type a letter (to start blinking) and then focus
> another window and check the terminal cursor. Does it stop blinking and
> becomes an outlined rectangle as expected, or does it keep blinking and/or
> remains a filled rectangle as if you did not switch away from that window?

Hi, Egmont.  This is an example of the gnome-terminal bug while it's happening.

As mentioned, no one knows what causes it to manifest itself.  But if I use gnome-terminal for an hour or so, switching between screens, it will happen.

Please take a look at:

https://youtu.be/T4-cDr4fKfs

If you want me to perform any experiments on the computer, or the gnome-terminal window while it's happening, I'll gladly oblige.

-- L. James

-- 
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames

Given that I can reliably reproduce this bug under gnome-shell (see comment 58), I tried debugging it a bit and it is, indeed, as Egmont said, due to the lack of focus-in/out events from gtk+.

The gtk+ patch in bug 677329 does fix it for me - at least for the reproducer described in comment 49

(In reply to Stephen Gallagher from comment #38)
> (In reply to M C Nelson from comment #36)
> > The first way I read that is that its a feature not a bug.
> > 
> > Its hard to see how someone would intend that behavior.  It seems more
> > likely that someone neglected to get the mouse events when it passes over
> > the exposed part of the window.
> 
> I think what M C was trying to say is that the feature of suppressing the
> mouse cursor from being displayed while typing is probably not worth the
> number of bugs that have come up because of it.
> 
> The suggestion being made was to drop the feature and simply never have the
> mouse cursor be hidden; then there would be no bugs with it failing to come
> back.
> 
> Ultimately, it's a value judgement: is keeping this feature important enough
> to justify spending time to fix bugs when it doesn't behave properly?

Unfortunately, the missing focus-in/out events issue manifests itself in various forms. For example, I learnt from Carlos Soriano that it affects nautilus too - the active window tracking gets confused and clicking in one window selects items in another. For similar reasons, as Egmont points out in bug 677329 , this confuses the proposed desktop notification system for gnome-terminal leading to missed notifications.

So, while I can understand the frustration, we should really try to fix this. The bug might be open for 2 years, but a reliable reproducer only showed up 2-3 weeks ago. (Thanks Egmont!) :)

Bug 677329 is fixed now, which means that in turn this bug is also fixed, yay!

(Please reopen _only if_ you applied the fix of 677329, double checked that gnome-terminal-server is linking against that fixed Gtk+, and the problem still persists.)

Thanks.  I'll do what I can do to apply the patch.

Can someone provide me with an exact link to the patch and how to apply it on Ubuntu 15.10?

This is what I find.  It this the right patch ( https://bugzilla.gnome.org/attachment.cgi?id=276710&action=edit )?

Do I apply it to the /usr/bin/gnome-terminal application?

-- L. James

-- 
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames

Just FYI: The fix has made it into the official Gtk+ 3.18.9 tarball, and in turn, has already appeared in Debian Unstable and in Ubuntu Xenial beta.

I'm not sure if this is the proper location for this, but I'd like to request that the autohide functionality be an option that can be configured to be turned off. I personally really dislike the autohiding altogether (i.e. not the bug everyone here is talking about, but the fact that it is ever hiding the cursor). I just recompiled the debian package myself using a modified version of the rejected patch attached to this thread (i.e. this one: https://bugzilla.gnome.org/attachment.cgi?id=319222&action=edit), but it would be nice if this were an option one could turn off and on without recompiling...

Thanks for all the good work done to all volunteers.