When we process the tickler message in our windows message pump, we should not dispatch
all window messages specifically if we are in the context of a Windows modal loop, i.e.
a Windows API like TrackPopupMenu, etc. This is because these API's expect to handle
input messages like keyboard and mouse messages by peeking them from the queue and handling
them. Our message pump currently dispatches all windows messages while processing the tickler
message which causes the windows modal loop to not see keyboard and mouse messages at times.
Added a flag in the windows message loop which indicates if we are in the context of an
os modal loop. If yes we just peek for WM_PAINT and timer and dispatch those and get out.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=59864
BUG=59864
Review URL: http://codereview.chromium.org/6676099
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@79248 0039d316-1c4b-4281-b951-d872f2087c98
CrOS-Libchrome-Original-Commit: 2ec01fe90944d9489cc3949c80fcc0826f9b1c76
diff --git a/base/message_loop.cc b/base/message_loop.cc
index 85e37d4..39881d1 100644
--- a/base/message_loop.cc
+++ b/base/message_loop.cc
@@ -123,6 +123,9 @@
nestable_tasks_allowed_(true),
exception_restoration_(false),
state_(NULL),
+#ifdef OS_WIN
+ os_modal_loop_(false),
+#endif // OS_WIN
next_sequence_num_(0) {
DCHECK(!current()) << "should only have one message loop per thread";
lazy_tls_ptr.Pointer()->Set(this);