Primary plugin hit detection needs to run after plugin creation
https://bugs.webkit.org/show_bug.cgi?id=112206

Reviewed by Tim Horton.

On some pages, the plugins are created after the page has loaded, and
thus our heuristic to determine the primary plugin fails. Run this
heuristic more often: after each PluginView is created. It already exits
early if it has found a primary. But we also need to make sure that it
doesn't run before load.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::addPluginView): Run detection when view is added.
(WebKit::WebPage::didFinishLoad): Remember that we have loaded.
(WebKit::WebPage::determinePrimarySnapshottedPlugIn): Look at the PluginViews to see if we have a plugin.
(WebKit::WebPage::resetPrimarySnapshottedPlugIn): Reset both flags.
* WebProcess/WebPage/WebPage.h:
(WebPage): New member variable, m_readyToFindPrimarySnapshottedPlugin.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@145644 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't send events to plugins that are being snapshotted
https://bugs.webkit.org/show_bug.cgi?id=112215
<rdar://problem/13386224>

Reviewed by Tim Horton.

If a plugin is in the process of being snapshotted, do not forward it
any events. This avoids the case where we can accidentally capture some
custom mouse pointers, as well as trigger a plugin menu.

The next step will be to detect if the event should stop the snapshotting
(restart the plugin).

* html/HTMLPlugInElement.cpp:
(WebCore::HTMLPlugInElement::defaultEventHandler): Return early if the plugin is snapshotting.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@145645 268f45cc-cd09-0410-ab3c-d52691b4dbfc