Prefer ScopedNestableTaskAllower over manual save/restore

chrome/browser/automation/automation_provider_win.cc

Index: chrome/browser/automation/automation_provider_win.cc
diff --git a/chrome/browser/automation/automation_provider_win.cc b/chrome/browser/automation/automation_provider_win.cc
index bcc8f63628a1aa3d7680f05f751ccc556e0cb80c..b373d5534489373f772de41f251724553b44853b 100644
--- a/chrome/browser/automation/automation_provider_win.cc
+++ b/chrome/browser/automation/automation_provider_win.cc
@@ -149,11 +149,9 @@ void AutomationProvider::WindowSimulateDrag(
           false,
           MessageLoop::QuitClosure());
       MessageLoopForUI* loop = MessageLoopForUI::current();
-      bool did_allow_task_nesting = loop->NestableTasksAllowed();
-      loop->SetNestableTasksAllowed(true);
+      MessageLoop::ScopedNestableTaskAllower allow(loop);
       views::AcceleratorHandler handler;

[jar (doing other things), 2012/02/11 03:24:38]

nit: although this mimics the existing code... IMO, we should construct the
handler outside of the scope of the nestable message loop, just so that we don't
accidentally(?) have any potential for running a nested loop (invisibly).

I'd suggest exchanging lines 152 and 153.

[dhollowa, 2012/02/13 17:44:26]

Done.

       loop->RunWithDispatcher(&handler);
-      loop->SetNestableTasksAllowed(did_allow_task_nesting);
     }
     SendMessage(top_level_hwnd, up_message, wparam_flags,
                 MAKELPARAM(end.x, end.y));