Community
Participate
Working Groups
Created attachment 184385 [details] snippet that creates a resize tracker on a tree, and lags in resize event I have a resize tracker that has as parent a tree widget. If the resize handler takes a considerable amount of time, the tracker changes the position of the mouse to the location previous to the resize operation. I attached a snippet where a tracker is used to select tree items, trying to imitate the explorer/nautilus behaviour. I know the snippet wastes CPU by changing the selection at each resize event, but that is the point: to make the tracker move the mouse position. Also, the speed of the tree is handled by another ticket. To observe the bug, just drag the mouse inside the tree. You will notice that the mouse will jump back and will slow the movement, making it difficult to exit the shell.
You could easily improve your code by not calling select() when the array of items returned by 'getItems(tree, bounds);' is the same. Does that solve your problem ? Note that getting/setting the selection on large Tree is slow in the OS, we were never able to workarond this problem on windows (see Bug 259141 and other).
(In reply to comment #1) Thank you for your answer. I already did that improvement, and indeed, it works much better. This is already in production code. I did not optimize the snippet in order to emphasize the wrong behaviour of the tracker. Thus, the ticket is no show stopper. You can lower the priority, as far as I am concerned.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
The behavior changed: mouse no longer remains in the old position. It now oscillates between the new position and the old position. Basically you see two mouse pointers. The bigger the window, the easier it is to reproduce. But then again, this feature is not used often, and I received no complain on my side in almost 10 years, so I don't mind if you close the ticket as WONTFIX.
Created attachment 280009 [details] Tracker border scraps The tracker probably need more than one fix. See screenshot where I moved mouse from bottom to top and back to bottom.
