diff options
author | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-09 01:23:05 +0000 |
---|---|---|
committer | ananta@chromium.org <ananta@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-09 01:23:05 +0000 |
commit | 1ee9333bab95dc5b414a8d18015da2ff103619f3 (patch) | |
tree | ba898139f30e5a24844e911bfc7ec67d7583e8b6 /chrome/renderer/render_widget.h | |
parent | 2c921642bf98d54fa4bd272a06c3fb77d7280cf9 (diff) | |
download | chromium_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.h | 4 |
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(). |