The following is Windows specific, but it may very well apply to other operating systems.
If you find yourself writing code that needs to know the position of the mouse cursor, and you don't have easy access to the last mouse move event, you may find it tempting to call GetCursorPos<http://msdn.microsoft.com/en-us/library/ms648390(VS.85).aspx>. Afterall, it returns the position of the mouse cursor. However, using this function can result in subtle (and annoying) bugs such as http://crbug.com/2993. It turns out that since GetCursorPos returns the mouse position "right now", it can actually confuse code that is also receiving inputs from mouse events. The message queue may be behind in processing mouse input events, and so the time sequencing of mouse movement as observed by GetCursorPos may appear out of sync with the delivery of mouse button events. The solution: Instead of calling GetCursorPos you should either refactor your code to be able to access input from mouse events consistently, or if that is not feasible then call GetMessagePos<http://msdn.microsoft.com/en-us/library/ms644938(VS.85).aspx> instead of GetCursorPos. That method returns the mouse position that was last observed by the event loop. By by unwanted detached tabs, -Darin --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
