diff options
| author | jon@chromium.org <jon@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-11-04 16:40:29 +0000 |
|---|---|---|
| committer | jon@chromium.org <jon@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-11-04 16:40:29 +0000 |
| commit | 738dce1a14e4f5b6bd8a8240098c9e24a9bfbf02 (patch) | |
| tree | 71c3c48e1c33bcc65e743253f6da9b579ef7e617 | |
| parent | 54c3f2c16cdf8cbfabbb2a972362416de005e3d3 (diff) | |
| download | chromium_src-738dce1a14e4f5b6bd8a8240098c9e24a9bfbf02.zip chromium_src-738dce1a14e4f5b6bd8a8240098c9e24a9bfbf02.tar.gz chromium_src-738dce1a14e4f5b6bd8a8240098c9e24a9bfbf02.tar.bz2 | |
Merge 30668 - DeferredAutoreleasePool didn't work on Snow Leopard.
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
TBR=mark@chromium.org
Review URL: http://codereview.chromium.org/365003
git-svn-id: svn://svn.chromium.org/chrome/branches/229/src@30964 0039d316-1c4b-4281-b951-d872f2087c98
| -rw-r--r-- | chrome/browser/renderer_host/render_widget_host_view_mac.mm | 15 |
1 files changed, 10 insertions, 5 deletions
diff --git a/chrome/browser/renderer_host/render_widget_host_view_mac.mm b/chrome/browser/renderer_host/render_widget_host_view_mac.mm index 4c12e9c..4e5cdec 100644 --- a/chrome/browser/renderer_host/render_widget_host_view_mac.mm +++ b/chrome/browser/renderer_host/render_widget_host_view_mac.mm @@ -5,7 +5,7 @@ #include "chrome/browser/renderer_host/render_widget_host_view_mac.h" #include "base/histogram.h" -#include "base/scoped_nsobject.h" +#import "base/scoped_nsobject.h" #include "base/string_util.h" #include "base/sys_string_conversions.h" #include "chrome/browser/browser_trial.h" @@ -554,8 +554,7 @@ void RenderWidgetHostViewMac::SetBackground(const SkBitmap& background) { if (ignoreKeyEvents_) return; - // TODO(avi): Possibly kill self? See RenderWidgetHostViewWin::OnKeyEvent and - // http://b/issue?id=1192881 . + scoped_nsobject<RenderWidgetHostViewCocoa> keepSelfAlive([self retain]); // Don't cancel child popups; the key events are probably what's triggering // the popup in the first place. @@ -591,7 +590,14 @@ void RenderWidgetHostViewMac::SetBackground(const SkBitmap& background) { // To send an onkeydown() event before an onkeypress() event, we should // dispatch this NSKeyDown event AFTER sending it to the renderer. // (See <https://bugs.webkit.org/show_bug.cgi?id=25119>). - if ([theEvent type] == NSKeyDown) + // + // If this object's retainCount is 1, the only reference is the one held by + // keepSelfAlive. All other references may have been destroyed in the + // RenderWidgetHost::ForwardKeyboardEvent call above if it resulted in tab + // closure. Were it not for that single reference, this object would + // already be deallocated. In that case, there's no point in calling + // -interpretKeyEvents:. + if ([self retainCount] > 1 && [theEvent type] == NSKeyDown) [self interpretKeyEvents:[NSArray arrayWithObject:theEvent]]; // Possibly autohide the cursor. @@ -1255,4 +1261,3 @@ extern NSString *NSTextInputReplacementRangeAttributeName; } @end - |