On trunk, if we have an nsObjectFrame that means we have a plug-in, or are trying to have one.

so er, why does SVG dislike frame reconstructs?

No clue. tor, do you know? Perhaps we should file a followup bug on that.

Comment on attachment 200697 [details] [diff] [review] Like so hmm, maybe a frame owned the docshell or something? if so, that should be fixed on trunk. I don't really like this very much, couldn't we do this in a more direct way instead of relying on the side effects of frame construction? (this will also break once plugin loading moves to content, but that is probably not going to happen soon :) ) r=biesi I suppose, since this is certainly better than the frame property.

When plugin loading moves to content, we'll just expose content apis to restart the plug-in... ;)

yes, my point is, should we do that now? We can do it - nsObjectLoadingContent could expose that API and implement it using mURI/mContentType.

Hmm... Maybe, yes. So what should the API look like? void reinstantiatePlugin(); ? And just do nothing if it's not a plugin?

hmm. maybe even stop() and start(), throwing if it is not a plugin?

Per discussion with biesi, let's do this for now, and then when we move more of plugins into content step back and reevaluate exactly how plugins and bfcache should interact.

biesi removed this code in bug 315841.