summaryrefslogtreecommitdiffstats
path: root/base/message_pump_mac.mm
Commit message (Collapse)AuthorAgeFilesLines
* Cleans up our autorelease pool handling by making sure that an autorelease ↵dmaclach@chromium.org2009-11-051-13/+78
| | | | | | | | | | | | | pool isn't created while the app is handling an event sent via -[NSApp sendEvent]. Branches browser/chrome_application_mac into browser/chrome_browser_application and base/chrome_application. Renderers will run as chrome_applications, and browsers will run as chrome_browser_applications. BUG=26418, 25462, 25463, 25465 TEST=1) See bug 25857. 2) Start up. Open 3+ windows. 3)Quit. See bugs for other repro cases. Review URL: http://codereview.chromium.org/345051 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31135 0039d316-1c4b-4281-b951-d872f2087c98
* DeferredAutoreleasePool didn't work on Snow Leopard.mark@chromium.org2009-10-311-252/+31
| | | | | | | | | | | | | | | | | | | 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-31/+252
| | | | | | | | | | | | | | | | | 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-2/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-14/+48
| | | | | | | | | | | | | | | 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-58/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-14/+26
| | | | | | | | | | | | | 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-13/+28
| | | | | | | | | | | | 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
* Fix DOA problem with dev channel. If there is nojrg@chromium.org2009-07-151-0/+9
| | | | | | | | | | | | | | | | | ~/Library/Preferences/com.google.Chrome.plist, we do a 1st run dialog. This dialog spins a run loop and messes up MessageLoop. "Choke brutally" means, among other things, "never process IPC messages to/from render". Reference CLs: http://codereview.chromium.org/149082 http://codereview.chromium.org/149029 http://codereview.chromium.org/146006 Review URL: http://codereview.chromium.org/149662 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20712 0039d316-1c4b-4281-b951-d872f2087c98
* Gracefully do nothing when run loop sources fire and no delegate is available.mark@chromium.org2009-06-261-0/+26
| | | | | | | | | | | This can happen if foreign code spins the run loop without Run being on the stack. BUG=2708 TEST=none Review URL: http://codereview.chromium.org/149082 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19382 0039d316-1c4b-4281-b951-d872f2087c98
* When falling out of a nested loop, if higher-priority work is done, be sure tomark@chromium.org2009-06-251-0/+10
| | | | | | | | | | still arrange to run lower-priority work on a subsequent pass. BUG=13468 TEST=http://crbug.com/13468#c5 Review URL: http://codereview.chromium.org/149029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19305 0039d316-1c4b-4281-b951-d872f2087c98
* Allow work that was deferred on account of not being runnable in a nested loopmark@chromium.org2009-06-251-94/+173
| | | | | | | | | | 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
* Implement temporary First Run Dialog on OS Xjeremy@chromium.org2009-05-211-1/+6
| | | | | | | | | | | | | | | | | | | | | | We use a modal dialog with a single checkbox on OS X. We use the OSX defaults system since we want something quick and reliable. The dialog is displayed at a very early stage in Chrome startup (Before any subsystems start relying on the stats variable). This means there are a few quirks in displaying the UI. A change was also needed to our event handling code since when the dialog is shown we spin an event loop at a very early stage in the process lifetime. Changed default value for stats to false and updated unit tests to reflect that. Also some misc. minor cleanup. BUG=11971,12046 Review URL: http://codereview.chromium.org/115608 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16669 0039d316-1c4b-4281-b951-d872f2087c98
* Removed unneeded includes of base/time.h.thestig@chromium.org2009-03-161-0/+1
| | | | | | Review URL: http://codereview.chromium.org/48019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11766 0039d316-1c4b-4281-b951-d872f2087c98
* Depending on what runloop we're under, the autoreleasepool might not get cleanedthomasvl@chromium.org2009-02-031-0/+15
| | | | | | | | up until we get a UI event. So we make our CF Source layers use a local pool to make sure we don't collect too much memory before something dumps it. Review URL: http://codereview.chromium.org/20005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9059 0039d316-1c4b-4281-b951-d872f2087c98
* Provide autorelease pool management on the Mac in all types of message pumps.mark@chromium.org2008-09-251-3/+10
| | | | | | | Fix a few unit tests to use autorelease pools as needed. Review URL: http://codereview.chromium.org/3805 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2603 0039d316-1c4b-4281-b951-d872f2087c98
* Mac-specific CFRunLoop-based MessagePump implementationmark@chromium.org2008-09-231-0/+363
Review URL: http://codereview.chromium.org/444 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2521 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-06 11:31:02 +0000