Bugzilla – Full Text Bug Listing
| Summary: | Tracker moves mouse cursor | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Knut Radloff <knut_radloff> | ||||
| Component: | SWT | Assignee: | Grant Gayed <grant_gayed> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | snorthov | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | 2.1 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux-Motif | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 5089 | ||||||
| Attachments: |
|
||||||
|
Description
Knut Radloff
Created attachment 2045 [details]
test case
GG to investigate and advise. Can I expect a fix for this soon, within the M3 timeframe? This is blocking 5089 which is a P2. The goal is to fix all P2s for M3. I couldn't reproduce this quite as described. What I did observe: On aix (since our aix has a 3-button mouse): 1. pressing the middle button did not display the Tracker 2. holding the middle button did not display the Tracker 3. holding the middle button and moving the mouse did display and move the tracker, but didn't move the pointer abnormally 4. doing #3 and then pressing an arrow key moved the pointer to the top of the tracker On linux (2-button mouse): - all of the same results occurred by pressing both buttons to represent pressing the middle button on a 3-button mouse Moving the pointer on kyy presses (result 4) was a requested functionality from ui (bug 4796). It isn't currently planned to make changes here. If changing something here is very important then please mention to Steve. Strange, I do actually see the described behaviour on a different linux machine here. The underlying problem is that when the tracker checks the mouse masks they sometimes indicate that no mouse buttons are down, and hence no drag is happening. The example snippet is being tricky though. I've added println's and noticed that whenever the pointer position warps it's a result of the example opening a second Tracker for a given drag. I can make the bad beaviour not happen by adding track[0] = false to the example right before tracker.open(), which ensures that only one Tracker is ever opened for a given DragDetect. I still observe the mouse pointer jumping even with the change to the test case you suggest. It jumps from the location of the mouse down to the top center of the tracking rectangle as soon as I move the mouse. BTW: The original test case wasn't exactly what happens in Eclipse. Eclipse does not open more than one tracker. Knut, I just realized that we saw different behaviours above because I was dragging using a chord while you were dragging using just button 2. I replaced my mouse with a 3-button mouse and duplicated your behaviour by using just button 2. So a change was released on 10/28 that should fix this. Previously the tracker would only check mouse button 1 to determine if a drag was happening; this made the assumption that the drag was being done with a chord, which is obviously wrong if button 2 is being used. So please retry the test case using the swt from the 1105 integration build, and it should work for you now. Note that you still have to add the "track[0] = false" line as described above, otherwise your example can invoke tracker.open () with the mouse up, which is not correct. Verified that fixes for bug 5089 work with 20021108 build. Can mark this as fixed. Fixed. |