summaryrefslogtreecommitdiffstats
path: root/base/message_pump_mac.h
Commit message (Collapse)AuthorAgeFilesLines
* Switch to using TimeTicks rather than Time in message loopsjar@chromium.org2010-11-061-2/+2
| | | | | | | | | | Switch to using TimeTicks rather than Time so that we are not dependent on changes in the system clock. r=mbelshe,darin Review URL: http://codereview.chromium.org/3884001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65322 0039d316-1c4b-4281-b951-d872f2087c98
* `#pragma once` for app, base, chrome, gfx, ipc, net, skia, viewsthakis@chromium.org2010-07-261-0/+1
| | | | | | | | | BUG=50273 TEST=everything still builds, build is 10% faster on windows, same speed on mac/linux TBR: erg git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53716 0039d316-1c4b-4281-b951-d872f2087c98
* Added missing file to fix build.dmaclach@chromium.org2009-11-051-0/+18
| | | | | | | | | TEST=none BUG=none Review URL: http://codereview.chromium.org/371002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31141 0039d316-1c4b-4281-b951-d872f2087c98
* DeferredAutoreleasePool didn't work on Snow Leopard.mark@chromium.org2009-10-311-38/+1
| | | | | | | | | | | | | | | | | | | This is a backout of r30647, but also resurrects the change from http://codereview.chromium.org/341022 to work around the crash that r30647 solved much more elegantly. We can't really leave things broken on 10.6, though. I killed most of a perfectly good Friday evening trying to figure out how to salvage r30647, but the DeferredAutoreleasePool approach seems doomed without making private calls. This makes me really sad. BUG=25857, 26399, 26402 TEST=Does it launch on Snow Leopard now? Does it crash when you close windows? Review URL: http://codereview.chromium.org/339095 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30668 0039d316-1c4b-4281-b951-d872f2087c98
* Cleans up our autorelease handling so that we don't create a layered dmaclach@chromium.org2009-10-301-1/+38
| | | | | | | | | | | | | | | | | autorelease pool in our run loop source if there is one already on the stack above us. This allows Cocoa to clean up all the objects at the same time as it expects to do. There may be more "interesting" code that can be removed now that this is in. Initially we were going to implement it by checking the nesting levels of the runloops, but it turns out by the time sendEvent is called at the upper level we are already out of the "CFRunloopRun" call so our nesting count isn't a valid indicator of our state. TEST=1) See bug 25857. 2) Start up. Open 3+ windows. Quit. BUG=25857 Review URL: http://codereview.chromium.org/343024 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30647 0039d316-1c4b-4281-b951-d872f2087c98
* Reset the Mac message pump's delayed work timer upon waking from system sleep.mark@chromium.org2009-10-281-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | CFRunLoopTimers are implemented in terms of kernel ticks, a time base which is suspended while the system is sleeping. In order to properly perform delayed work at the proper initially-scheduled time (or at system wake if the scheduled time passed while the system was asleep), the associated timer needs to be reset to the most recently scheduled next-fire time on wake from sleep. BUG=22508 TEST= - Make Chrome the active application. - Close all Chrome windows. - Close the laptop lid. - Wait for it to begin sleeping, indicated by the pulsing light. NOTE: wait until the light actually begins pulsing, not just until it turns on. The disk and fans should all be stopped. - Reopen the laptop. If needed, authenticate to the screen saver. - Click the Chrome icon in the dock. A new window should open on the New Tab page. - Quickly type "google.com/" into the omnibox. - The page should load, its favicon should be visible, and the tab title should read "Google". This should happen as instantly as a normal page load. The tab title should not "stick" on "New Tab" and the icon load should not be delayed for any amount of time. Review URL: http://codereview.chromium.org/342011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30335 0039d316-1c4b-4281-b951-d872f2087c98
* Call MaybeScheduleNestingDeferredWork at the top of each loop iteration frommark@chromium.org2009-10-221-3/+10
| | | | | | | | | | | | | | | a kCFRunLoopBeforeSources observer. A busy loop that's driven with a nonzero duration might not go to sleep or exit soon after a nested loop exits, so calling MaybeScheduleNestingDeferredWork from the existing kCFRunLoopBeforeWaiting and kCFRunLoopExit observers may not be sufficient to guarantee processing of nesting-deferred work in all situations. BUG=24968 TEST=All of the test cases listed in the commit message from r29749. No new test cases; this change addresses a purely theoretical case. Review URL: http://codereview.chromium.org/315010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29775 0039d316-1c4b-4281-b951-d872f2087c98
* Change the strategy used to attempt nesting-deferred work to account equallymark@chromium.org2009-10-221-15/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* When a nested run loop is driven directly by Run/DoRun as opposed to being amark@chromium.org2009-10-131-4/+4
| | | | | | | | | | | | | 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 Review URL: http://codereview.chromium.org/264042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28811 0039d316-1c4b-4281-b951-d872f2087c98
* When work shows up and no delegate is available to dispatch it to, arrange tomark@chromium.org2009-07-151-0/+9
| | | | | | | | | | | | dispatch to the delegate when one becomes available. BUG=16732 TEST=rm ~/Library/Preferences/com.google.Chrome.plist, launch official-branding Google Chrome, dismiss first-run dialog. The application should be usable. Review URL: http://codereview.chromium.org/149687 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20770 0039d316-1c4b-4281-b951-d872f2087c98
* Allow work that was deferred on account of not being runnable in a nested loopmark@chromium.org2009-06-251-23/+50
| | | | | | | | | | to be processed when returning to an outer loop. BUG=11470 13442 13468 TEST=base_unittests, test cases in bugs Review URL: http://codereview.chromium.org/146006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19272 0039d316-1c4b-4281-b951-d872f2087c98
* Removed unneeded includes of base/time.h.thestig@chromium.org2009-03-161-2/+2
| | | | | | Review URL: http://codereview.chromium.org/48019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11766 0039d316-1c4b-4281-b951-d872f2087c98
* Mac-specific CFRunLoop-based MessagePump implementationmark@chromium.org2008-09-231-0/+181
Review URL: http://codereview.chromium.org/444 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2521 0039d316-1c4b-4281-b951-d872f2087c98