diff options
| author | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-10-31 15:35:26 +0000 |
|---|---|---|
| committer | mark@chromium.org <mark@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-10-31 15:35:26 +0000 |
| commit | 070131d12c5e5a9c29baa1d8ee28d5271a088a18 (patch) | |
| tree | ccb34df6997427a41a6f8679ab3003bb28d7ae61 /chrome/browser/renderer_host | |
| parent | 9eb8f98b6f7582ce25ba8cac11827edb8a08a5eb (diff) | |
| download | chromium_src-070131d12c5e5a9c29baa1d8ee28d5271a088a18.zip chromium_src-070131d12c5e5a9c29baa1d8ee28d5271a088a18.tar.gz chromium_src-070131d12c5e5a9c29baa1d8ee28d5271a088a18.tar.bz2 | |
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
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30668 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/browser/renderer_host')
| -rw-r--r-- | chrome/browser/renderer_host/render_widget_host_view_mac.mm | 20 |
1 files changed, 15 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 a73e180..956e253 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" @@ -289,6 +289,11 @@ void RenderWidgetHostViewMac::Destroy() { [subview renderWidgetHostViewMac]->ShutdownHost(); } + // We've been told to destroy. + [cocoa_view_ retain]; + [cocoa_view_ removeFromSuperview]; + [cocoa_view_ autorelease]; + // We get this call just before |render_widget_host_| deletes // itself. But we are owned by |cocoa_view_|, which may be retained // by some other code. Examples are TabContentsViewMac's @@ -549,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. @@ -586,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. @@ -1250,4 +1261,3 @@ extern NSString *NSTextInputReplacementRangeAttributeName; } @end - |