313687 - [FIX]Clean up fix of bug 313669 for trunk

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[Boris Zbarsky [:bzbarsky]]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

so er, why does SVG dislike frame reconstructs?

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm...  Maybe, yes.  So what should the API look like?

  void reinstantiatePlugin();

?  And just do nothing if it's not a plugin?

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

biesi removed this code in bug 315841.