Terminate plugins as well as runing onunload handlers during slow shutdown.

Terminate plugins as well as runing onunload handlers during slow shutdown.

This implementation uses the existing OnDestruct method. This is called in
a state where webkit is still intact, so any callbacks by the plugin should
still function properly.

BUG=https://code.google.com/p/flapper/issues/detail?id=120
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=135901

[Tom Sepez, 2012-05-08 00:41:37]

Brett,  please review.  Last piece of the LSO shutdown fix.

[brettw, 2012-05-08 18:26:53]

I'm a little concerned about this. I'd like to understand a bit more about the
destruction order.

I would have expected WebKit to destroy the plugins when a page is being
destroyed. Do we know why this isn't happening? What is the relative destruction
order between the WebKit stuff (Frame, etc.) and the RenderView?

I'm asking because PluginInstance::Delete which this now calls, calls into the
instance interface DidDestroy. This is a sync message. The plugin may start
deleting stuff or tearing down stuff, some of which may be sync messages back to
the renderer. These can in turn call into WebKit. If WebKit is already torn
down, this will crash. We've had problems like this in the past.

[Tom Sepez, 2012-05-08 19:03:04]

Webkit does destroy the plugins when the page is being destroyed.  But as part
of normal shutdown, it appears that we're efficient and do not destroy the page.
RenderViewImpl::OnShouldClose() only runs the onload handlers, leaves the page
intact, and exits.

I didn't expect the possibility of going back into webkit. But it makes sense
that this might happen.

If OnShouldClose sends back an ack with should_close == false, do we run the
full shutdown?  Is that the right way to do it?

[Tom Sepez, 2012-05-08 19:05:02]

Note: by "and exits", I mean it terminates its main loop without doing any
further webkit cleanup.

[Tom Sepez, 2012-05-08 19:25:42]

Note: returning false as suggested above keeps the renderer alive without
further shutdown steps - not an option.

Sooo ... the other thing I can think of is to add a new ppapi message here to
flush state without actually destroying the plugin, since this is what we want
(and what we were getting as a side effect of destroying the plugin cleanly). 
Maybe somethng like "WillDestroy".

[Tom Sepez, 2012-05-08 20:00:30]

Convinced webkit is still intact, so the initial approach should be acceptable. 
Also, do not terminate the plugin if the webpage blocks unload.

[brettw, 2012-05-08 20:03:11]

Can you add a comment in PluginInstance::Delete as well about the two types of
deletion?

[Tom Sepez, 2012-05-08 20:14:50]

Done.

[brettw, 2012-05-08 20:37:03]

lgtm