On 2016-12-31 07:34:36 -0700, Jaimos Skriletz wrote: > A summary of why I reassigned the bug. > > It appears that this bug is with unclutter and not fvwm. I have > tested this all in stretch. Using the wheezy version of > unclutter (8-18) this bug is not present. Using the jessie (8-19) > or stretch (8-20) version this bug is present.
I've just looked at /usr/share/doc/unclutter/README and it says (hoping that this is still valid): " unclutter is a program which runs permanently in the background of an X11 session. It checks on the X11 pointer (cursor) position every few seconds, and when it finds it has not moved (and no buttons are pressed on the mouse, and the cursor is not in the root window) it creates a small sub-window as a child of the window the cursor is in. The new window installs a cursor of size 1x1 but a mask of all 0, ie an invisible cursor. This allows you to see all the text in an xterm or xedit, for example. The human factors crowd would agree it should make things less distracting. Once created, the program waits for the pointer to leave the window and then destroys it, restoring the original situation. Button events are passed transparently through to the parent window. They will usually cause the cursor to reappear because an active grab will be made by the program while the button is down, so the pointer will apparently leave the window, even though its x y position doesnt change. " If I understand correctly, this way of doing is incorrect because it yields incorrect hover information. It's also a lie from the description of unclutter, which doesn't just hide the cursor. This would mean that bug 808425 (iceweasel: hover status becomes false when the mouse pointer is invisible) is a duplicate. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
