Bug 3779 - mouse cursor/pointer disappears forever, in compose window
Summary: mouse cursor/pointer disappears forever, in compose window
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: UI/Compose Window (show other bugs)
Version: 3.14.1
Hardware: PC Linux
: P3 minor
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2017-03-05 13:02 CET by thewildbeast.co.uk
Modified: 2017-03-12 10:57 CET (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description thewildbeast.co.uk 2017-03-05 13:02:59 CET
When composing a message, the mouse cursor disappears as soon as one starts to type.

However, randomly, the mouse pointer will disappear and never return until you move the mouse pointer outside of the compose window entirely.

This means that highlighting text, copying and pasting are effectively impossible -- as, you have zero idea where the cursor is.

Debian Jessie, 3.14.1 backports and 3.11.1 both exhibit this problem.
Comment 1 thewildbeast.co.uk 2017-03-05 13:07:15 CET
Additional info.

"Randomly" means "randomly, during the compose session".  Every single time I compose an email, this happens, but it does not happen instantly.

I have not yet seen a pattern which is visually apparent depending upon the text I type.  For example, I thought perhaps the spell checker might cause some code to fire, which borked the "re-appear when moved" cursor code -- but no.

As well, if you right click (to bring up the menu), or left click -- the cursor will reappear when you move it.

Older versions of claws, it seems to be, simply re-exhibited the pointer.  Like all other apps do.
Comment 2 Paul 2017-03-06 19:33:35 CET
Never encountered that, and never seen it reported previously. Looks like a local problem. I think if you tried those other versions of claws-mail I'd bet they now do the same on your system.
Comment 3 thewildbeast.co.uk 2017-03-07 15:04:41 CET
And yet -- absolutely no other application behaves this way on my system.

There are indeed particulars to my system, which are unique.  All systems are this way.  For example, I use a 4k display.  It could be that DPI or screen size is somehow messing up claw's algorithm that determines when to make the mouse cursor re-appear.

Yet -- no other app seems to hide my cursor, then never allow it to re-appear until I move outside of its compose window.

This indeed seems like a claws bug.

Do you have no other answer, no other information you would like -- instead of simply closing INVALID?  This seems to be jumping the gun a bit...
Comment 4 Paul Rolland 2017-03-07 16:16:07 CET
Hello,

> When composing a message, the mouse cursor disappears as soon as one starts to 
> type.

Same here, always considered that as a feature, especially as gvim behaves the same: as soon as you start type, mouse pointer is hidden and you need to move the mouse to have it back.

> However, randomly, the mouse pointer will disappear and never return until you 
> move the mouse pointer outside of the compose window entirely.

Never happened....
Comment 5 Michael Schwendt 2017-03-07 16:41:19 CET
> When composing a message, the mouse cursor disappears as soon as
> one starts to type.

That's normal. Other editors, such as GEdit or Emacs, do that, too, so the cursor doesn't disturb your view. Simply moving the mouse makes the pointer reappear.

Btw, unconfirmed and dubious issues like this are better discussed on the mailing-list instead of entering a bug report right away.
Comment 6 Paul 2017-03-07 16:42:30 CET
(In reply to comment #3)
> And yet -- absolutely no other application behaves this way on my system.

What other GTK2 apps on your system do not show this?
Comment 7 thewildbeast.co.uk 2017-03-07 18:07:41 CET
Good grief.

Can we cut the 'it's supposed to disappear!' comments?  Yes, of course it is.  At no time did anyone, including me, state that it shouldn't disappear.

It's merely *information*, to aid in the debug flow.

And while we're at it, could we cut the 'it's never happened to me!' comments?  Clearly, if it happened to "you", you'd have filed a bug.  Or looked at the code.  Or, you know, said or done something.

Back to the bug, instead of all of this cross talk...

Paul -- gvim (debian's vim-gtk package) exhibits this behaviour correctly.  I start to type, cursor disappears.  I move the mouse, cursor reappears.  No clicking is required to make the mouse cursor reappear.

Same user account, same system.

This has been going on for about a year -- but, I've finally had some cycles to deal with this now.

With all this cross talk, and pointless "me too!" and "it's supposed to disappear" blather, enough.  You were right to close this bug, Paul.

After all, there is zero movement on your end to actually think about it, ponder it, or debug it.  Or, you know, even take bug reports seriously.

Marked 'resolved' because "fuck this noise".
Comment 8 Paul 2017-03-07 18:31:06 CET
(In reply to comment #7)

Thank you not-your-domain-name@your-domain-name for your patience and kind words. The behaviour you described by mixing your terms is how GTK works, this is why it is INVALID.
Comment 9 Michael Schwendt 2017-03-12 10:57:43 CET
> gvim (debian's vim-gtk package) exhibits this behaviour correctly.
> I start to type, cursor disappears.  I move the mouse, cursor reappears.
> No clicking is required to make the mouse cursor reappear.

Earlier you've only claimed you need to move the mouse pointer out of the window completely for it to reappear, now you have to click somewhere?

Also:

> All systems are this way.  For example, I use a 4k display. 

"All systems"? What are the notable differences between the systems, their hardware and runtime portions?

Which window managers or desktop managers have you tried so far?