summaryrefslogtreecommitdiffstats
path: root/chrome/renderer/render_widget.h
diff options
context:
space:
mode:
authorananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-06-09 01:23:05 +0000
committerananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-06-09 01:23:05 +0000
commit1ee9333bab95dc5b414a8d18015da2ff103619f3 (patch)
treeba898139f30e5a24844e911bfc7ec67d7583e8b6 /chrome/renderer/render_widget.h
parent2c921642bf98d54fa4bd272a06c3fb77d7280cf9 (diff)
downloadchromium_src-1ee9333bab95dc5b414a8d18015da2ff103619f3.zip
chromium_src-1ee9333bab95dc5b414a8d18015da2ff103619f3.tar.gz
chromium_src-1ee9333bab95dc5b414a8d18015da2ff103619f3.tar.bz2
Fixes a flash plugin hang caused by opening google finance ticker symbols in a background tab.
From what I can tell this bug always existed in Chrome. The flash plugin gets instantiated and gets initial geometry updates during initialization. We download the plugin url after the geometry update. After these geometry updates the webkit layout timer runs and the plugin gets additional geometry updates. However these don't get sent over to the flash plugin instance in the plugin process as the geometry updates for windowed plugins are only flushed during paint, which does not happen in this case. The flash plugin ends up receiving data before geometry update and ends up behaving in a wierd fashion, i.e. not peeking for messages, etc. The fact that this is a windowed plugin results in the browser ui thread also getting hung until the plugin gets out of this state. The fix for the geometry update issue is to remove the deferred geometry update stuff. This only exists for windowed plugins anyway. The geometry update IPC is a plain routed message and it should not be a big overhead to send these IPCs to the plugin process. I found that while this change fixes the basic issue, we still see some hangs in the flash plugin because of it receiving data before the valid geometry update kicks in. John is working on a fix where we never have to call setFrameRect ourselves and always honor the setFrameRect calls made by Webkit. This issue can be marked as fixed once both fixes get checked in. This fixes http://code.google.com/p/chromium/issues/detail?id=12993 Bug=12993 TEST=Open google finance and Ctrl Click on the tickers in the page like Basic Materials, etc. Review URL: http://codereview.chromium.org/119200 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17918 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/renderer/render_widget.h')
-rw-r--r--chrome/renderer/render_widget.h4
1 files changed, 0 insertions, 4 deletions
diff --git a/chrome/renderer/render_widget.h b/chrome/renderer/render_widget.h
index a337f54..440a7e2 100644
--- a/chrome/renderer/render_widget.h
+++ b/chrome/renderer/render_widget.h
@@ -123,10 +123,6 @@ class RenderWidget : public IPC::Channel::Listener,
void DoDeferredClose();
void DoDeferredSetWindowRect(const WebKit::WebRect& pos);
- // This method is called immediately after PaintRect but before the
- // corresponding paint or scroll message is send to the widget host.
- virtual void DidPaint() {}
-
// Set the background of the render widget to a bitmap. The bitmap will be
// tiled in both directions if it isn't big enough to fill the area. This is
// mainly intended to be used in conjuction with WebView::SetIsTransparent().