Looks like the m_pluginWidget member of FrameLoaderClientImpl is keeping the widget alive past the destruction of the document. This keeps the instance registered so that a delayed GetWindowObject is still processed, rather than just erroring upon enter. The plugininstance has a raw ptr to a webplugincontentsimpl which has a raw ptr to an HTMLPluginElement from the document which no longer exists.
Now, the m_pluginWidget is just about to be cleared by FrameLoaderClientImpl::redirectDataToPlugin (called from PluginDocumentParser::appendBytes), but before that can happen, layout causes the plugin to be created, which processes a sync message, which can catch the delayed GetWindowObject in its nested message loop.

So here's a change that solves the problem. Seems similar to https://bugs.webkit.org/show_bug.cgi?id=66517 so adding author/reviewer of that patch to ask the question: Is this an appropriate place to clear the m_pluginWidget? Or is there some method that didn't happen in the PPAPI case that should have taken care of this? Let me know if this is OK and I'll file a bug upstream to land it.
Index: third_party/WebKit/Source/WebKit/chromium/src/FrameLoaderClientImpl.cpp
===================================================================
--- third_party/WebKit/Source/WebKit/chromium/src/FrameLoaderClientImpl.cpp (revision 123007)
+++ third_party/WebKit/Source/WebKit/chromium/src/FrameLoaderClientImpl.cpp (working copy)
@@ -133,12 +133,16 @@
void FrameLoaderClientImpl::dispatchDidClearWindowObjectInWorld(DOMWrapperWorld*)
{
+ // Don't let the plugin widget outlive the rest of the page.
+ m_pluginWidget = 0;
if (m_webFrame->client())
m_webFrame->client()->didClearWindowObject(m_webFrame);
}
void FrameLoaderClientImpl::documentElementAvailable()
{
+ // Verify that the plugin widget didn't outlive the rest of the page.
+ ASSERT(!m_pluginWidget);
if (m_webFrame->client())
m_webFrame->client()->didCreateDocumentElement(m_webFrame);
}

Adding abarth@, who knows things about the document-loader code.
We've had niggling issues with plugin widget lifetimes seemingly forever; various parts of WebKit assume that they won't outlive the page but at some point that guarantee has been broken - it's possible that this change could fix a swathe of such issues, if the FrameLoaderClientImpl's reference to the widget is the root cause of it living too long.