This fixes http://code.google.com/p/chromium/issues/detail?id=772,
which was an issue with the browser UI thread entering a tight loop
at times. The thread inputs of the browser UI thread and the plugin thread
are attached due to the parent child relationship between the windows.
As a result at times the MsgWaitForMultipleObjectsEx API returns the
fact that there are messages in the queue (mouse messages). The subsequent
peek fails to return any messages causing us to enter a loop for a while.
This also happens when the plugin has capture and just before it releases capture, some mousemoves end up in the browser ui thread causing a tight loop.
The fix is to check if there are mouse messages in the queue by invoking
GetQueueStatus and attempting to peek them out with PM_NOREMOVE. If this
fails we call WaitMessage to block until the next message.
The other fix is to return true from ProcessNextWindowsMessage if PeekMessage returns false and there were sent messages in the queue, as
this is as expected. This will ensure that we go back up and peek again
instead of calling MsgWaitForMultipleObjectsEx again.
Bug=772
R=darin
Review URL: http://codereview.chromium.org/6021
git-svn-id: svn://svn.chromium.org/chrome/trunk@2740 0039d316-1c4b-4281-b951-d872f2087c98
1 file changed
