Bugzilla – Full Text Bug Listing
| Summary: | Posting mouse events locks up event handling | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Christof Marti <christof_marti> | ||||||
| Component: | SWT | Assignee: | Steve Northover <snorthov> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | andre_weinand, kai-uwe_maetzel, veronika_irvine | ||||||
| Version: | 3.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Christof Marti
Created attachment 14070 [details]
Example code
Example code that can post mouse events from main or background thread.
Adapting summary. The following was found using the attached source of comment 1. I observe the same lockup when posting the mouse events from the background thread if I comment the line "while (fDisplay.readAndDispatch());" in the EventPoster's constructor. (Only reproducible when running without the debugger.) Having removed the above line and moving "shell.open()" in MouseEvents.run() after the creation of the EventPoster works again. Also, replacing the computation of fMaxTopPixel in EventPoster's constructor by a precomputed value works. It never worked when posting from the main thread. (One of our laptops showed a similar lock up when running the MouseScrollEditorTest plug-in test, which runs fine on my machine.) I was able to capture a stack-trace while posting the events from the main thread: Thread [main] (Suspended) OS.DefWindowProcW(int, int, int, int) line: not available [native method] OS.DefWindowProc(int, int, int, int) line: 1467 StyledText(Scrollable).callWindowProc(int, int, int) line: 77 StyledText(Composite).WM_SYSCOMMAND(int, int) line: 956 StyledText(Control).windowProc(int, int, int, int) line: 3045 Display.windowProc(int, int, int, int) line: 3349 OS.DefWindowProcW(int, int, int, int) line: not available [native method] OS.DefWindowProc(int, int, int, int) line: 1467 StyledText(Scrollable).callWindowProc(int, int, int) line: 77 StyledText(Control).windowProc(int, int, int, int) line: 3055 Display.windowProc(int, int, int, int) line: 3349 OS.DispatchMessageW(MSG) line: not available [native method] OS.DispatchMessage(MSG) line: 1472 Display.readAndDispatch() line: 2440 MouseEvents$EventPoster.waitForScrolling(long) line: 95 MouseEvents$EventPoster.run() line: 77 MouseEvents.run() line: 127 MouseEvents.main(String[]) line: 111 I can't make the "comment out the readAndDispatch() in the constructor" case fail. I'm not sure exactly why the other case fails. When the mouse goes down in a scroll bar, Windows runs a modal loop that eats events until mouse up. The subsequent events don't go through readAndDispatch(). I think in order to get good timing you must post from another thread. You are running an event loop inside of the waitForScrolling() which is dispatching random events and taking up time? Not sure about this. The problem is that Windows is stuck in the modal loop in readAndDispatch(), looking for more input but it's not coming because there is only one thread. This can happing on any platform that has it's own message loop, even if the message loop is not in the operating system. For example, an custom dialog that is running an event loop waiting for the OK button to be pressed will never see the button press. Modal message loops happen in Window for scroll bars, menus, resizing and any native dialog. On the Mac, modal message looks happen in most native widgets when the left button is pressed. Investigating the multi thread hang. Do you have any ideas? No, both cases looked the same to me. The single thread case cannot be fixed. It's not actually a bug but "platform behavior" that we can't do anything about. Sorry. Christof, can you edit the attached code into a multi-thread case that hangs on your machine and attach that, just to make sure I'm not doing something dumb? Thanks. Created attachment 14788 [details] Source that locks up while posting from background Differences to attachment 14070 [details]: - POST_FROM_BACKGROUND is true - line 55 is commented This makes it hang on my machine. What additional information can I provide? It doesn't hang on my machine, but it also doesn't work. Scrolling stops around the 5th item. Veronika, can you try it on your machine? I called the 'stops around the 5th item' a 'hang' in previous comments. If I uncomment line 55 it works again. Sorrym "lock up" and "hang" around here usually mean crash the operating system. ;-) The OS is fine ;-) Eclipse's main thread hangs in the event loop. A manual click on the mouse 'unlocks' it again. Fixed > 20041002 The multi-thread case now works without the bogus event loop. The single thread case will never work (or is not working as expected). |