Last Comment Bug 311791 - bfcache doesn't stop plugins correctly
: bfcache doesn't stop plugins correctly
: fixed1.8
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
: Andrew Overholt [:overholt]
Depends on: 313669
Blocks: blazinglyfastback
  Show dependency treegraph
Reported: 2005-10-09 09:55 PDT by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2011-08-05 22:34 PDT (History)
6 users (show)
brendan: blocking1.8rc1+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Fix (1.15 KB, patch)
2005-10-21 20:08 PDT, Boris Zbarsky [:bz] (still a bit busy)
bryner: review+
bryner: superreview+
asa: approval1.8rc1+
Details | Diff | Splinter Review

Description Boris Zbarsky [:bz] (still a bit busy) 2005-10-09 09:55:10 PDT
This is an unfortunate consequence of nsPluginHostImpl registering itself with
two different CIDs.  As a result, you get two instances of it floating around.
nsObjectFrame stops the plugin on the instance that's gotten via the plugin
manager CID and contract, while presshell (for bfcache) uses the plugin host
contract, which means the plugins are not fully stopped...
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2005-10-09 10:28:38 PDT
The upshot is that we stop the plugin itself, but the plugin manager still
thinks the plugin is running, which breaks things like trying to unload the
plugin if plugin reload happens.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2005-10-21 20:08:27 PDT
Created attachment 200416 [details] [diff] [review]

Brian, if you can't get to this in time for it to make 1.8, please let me know
ASAP so I can ask someone else for review Sunday morning.  If you do get to
this tomorrow, could you go ahead and check it in?
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2005-10-21 20:11:00 PDT
I think this is something we should really fix on branch -- we don't want to be
creating a second instance of the plugin host (which is effectively what this
codepath does), since that makes it very unclear which one of them is actually
responsible for the running plugins.  This fix is very very safe, and I'm hoping
I'll get review by Sunday... :(
Comment 4 Brian Ryner (not reading) 2005-10-21 20:27:38 PDT
checked in on trunk.
Comment 5 Brian Ryner (not reading) 2005-10-22 11:23:35 PDT
checked in on branch.

Note You need to log in before you can comment on or make changes to this bug.