Change the strategy used to attempt nesting-deferred work to account equally
well for nested run loops under our own control (those started by Run) and
those beyond our control (native event loops).

Previously, upon any exit from a nested native loop, we would schedule
nesting-deferred work for processing.  However, some nested native loops do
not execute in a single loop; rather, they start and stop the CFRunLoop
rapidly.  In such cases, each exit from the CFRunLoop would cause
nesting-deferred work to be scheduled, and on each new entry to the CFRunLoop,
we would attempt to process it.  This rapid-fire action meant that we'd never
sleep.  Nested loops managed by Run were exempt from these problems since
r28811, because we could defer scheduling nesting-deferred work until
returning to Run.

The new strategy is to detect whether any nested loops (native or managed by
Run) had run before the run loop goes to sleep or exits.  If any nested loops
did run, nesting-deferred work is scheduled for processing.

BUG=24968
TEST=1. Test case from bug 24968, printing: open any page, press command-P,
        leave the dialog up, and check Chrome's CPU usage.  No Chrome process
        should be monopolizing any CPU.  This tests nested native run loops.
     2. Test case from bug 24337, JS alerts: open Gmail, start composing a new
        message in a new window, address it to yourself, move focus to the
        subject field, click the Discard button, and click "OK" at the alert.
        The alert and composition window should close.
     3. Test case from bug 24383, JS alerts: no Chrome processes should use
        100% CPU after visiting javascript:alert("hi").  The JS alert cases
        test nested run loops managed by Run.
     4. Test case from bug 13468 comment 5, autocomplete: autocomplete should
        still work after using "Back" from a contextual menu.  This tests
        that nesting-deferred work is processed after leaving a nested run
        loop.
     5. First run UI test case (no bug).  Remove or move aside the profile
        directory (~/Library/Application Support/Chromium or
        ~/Library/Application Support/Google/Chrome) and launch the
        application.  There should be first-run UI and it should be usable.
        Upon clicking "Start (application)", the application should start and
        be usable as normal.  This tests delegateless run loops and
        delegateless work redispatch.
     6. base_unittests --gtest_filter='MessageLoopTest.*'
Review URL: http://codereview.chromium.org/300044

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29749 0039d316-1c4b-4281-b951-d872f2087c98
2 files changed