Less busywork for nested Mac run loops

When a nested run loop is driven directly by Run/DoRun as opposed to being a
nested native loop run by code outside of our control, and the nested run loop
stops, don't schedule nesting-deferred work until returning fron Run/DoRun.

BUG=24337, 24383
TEST=With r28745 backed out or an equivalent change recommitted:
     1. Test case from bug 24337: the window should close
     2. Test case from bug 24383: no Chromium processes should use 100% CPU

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=28811

[Mark Mentovai, 2009-10-13 01:18:34]

I always have a hard time picking run loop reviewers.

[Mark Mentovai, 2009-10-13 02:25:15]

With r28745 backed out, this does fix bug 24337.

[John Grabowski, 2009-10-13 02:35:45]

Unit tests?

We've found a few knarly bugs down here.  Might be nice to increase the
confidence level.

[darin (slow to review), 2009-10-13 04:41:16]

Do you still need to run a TYPE_UI message loop in the renderer?-Darin

On Mon, Oct 12, 2009 at 6:18 PM, <mark@chromium.org> wrote:

> Reviewers: John Grabowski, TVL, darin,
>
> Message:
> I always have a hard time picking run loop reviewers.
>
> Description:
> When a nested run loop is driven directly by Run/DoRun as opposed to being
> a
> nested native loop run by code outside of our control, and the nested run
> loop
> stops, don't schedule nesting-deferred work until returning fron Run/DoRun.
>
> BUG=24337, 24383
> TEST=Type javascript:alert("x"); into the URL bar.  It should not cause any
>     Chromium processes to go to 100% CPU.  This test is only effective with
>     r28745 backed out (or an equivalent change recommitted).
>
> Please review this at http://codereview.chromium.org/264042
>
> SVN Base: svn://svn.chromium.org/chrome/trunk/src/
>
> Affected files:
>  M     base/message_pump_mac.h
>  M     base/message_pump_mac.mm
>
>
>

[TVL, 2009-10-13 12:08:03]

lg