Set plugin focus via element dispatch

third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp

Index: third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp
diff --git a/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp b/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp
index d596e313ddac407315aa006accb080faddbac240..07db048527dd63ddeaa418e2970d9182d6132b46 100644
--- a/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp
@@ -96,6 +96,24 @@ DEFINE_TRACE(HTMLPlugInElement) {
   HTMLFrameOwnerElement::trace(visitor);
 }
 
+void HTMLPlugInElement::dispatchBlurEvent(
+    Element* newFocusedElement,
+    WebFocusType type,
+    InputDeviceCapabilities* sourceCapabilities) {
+  if (PluginView* plugin = ownedPlugin())
+    plugin->setFocused(false, type);

[dcheng, 2017/04/05 07:48:08]

One potential subtlety that I'm not sure if we need to watch out for: I wonder
if it's possible for this to synchronously dispatch an event in the plugin,
which will run script, which will change the focus.

Elsewhere in setFocusedElement(), we bail out if the focus is changed in the
process of dispatching handlers: do we need that early bail out logic here? Is
it even possible to implement at this level?

[haraken, 2017/04/05 11:59:00]

Would it be crazy to call Element::dispatchBlurEvent and then setFocused?

[dcheng, 2017/04/05 21:14:44]

Either way, I think we may need to do a focus check to make sure focus state
didn't change, no matter which order we dispatch these things in.

[joelhockey, 2017/04/05 23:59:11]

I think this change will fix any potential bugs relating to the scenario that
you described.  Previously, the setFocus on plugins was done after the dispatch
events, and there were no checks about whether calling the plugin caused a
change of focus.  Now, the handling of plugins is the same as other elements. 
So as you say, if calling blur on the plugin causes the plugin to change the
focus, then the existing code in Document::setFocusedElement method catches it. 
See check that m_focusedElement gets set by dispatchBlurEvent.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Docum...

Likewise there is a check for (m_focusedElement != newFocusedElement) after the
call to dispatchFocusEvent that now comes into play for plugins.

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Docum...

[dcheng, 2017/04/06 03:01:33]

I guess my concern mostly regards the short-circuiting behavior: we didn't do
this for plugins previously, but it happened at the very end, after we
dispatched all the other JS events.

Now plugin event dispatch happens before the focus/blur event dispatched by the
subclass, and we don't check before calling through to the base class. I think
we probably should be?

[joelhockey, 2017/04/06 06:11:00]

I have updated to call the dom onblur/onfocus first, and then call the plugin.

+  Element::dispatchBlurEvent(newFocusedElement, type, sourceCapabilities);
+}
+
+void HTMLPlugInElement::dispatchFocusEvent(
+    Element* oldFocusedElement,
+    WebFocusType type,
+    InputDeviceCapabilities* sourceCapabilities) {
+  if (PluginView* plugin = ownedPlugin())
+    plugin->setFocused(true, type);
+  Element::dispatchFocusEvent(oldFocusedElement, type, sourceCapabilities);
+}
+
 // TODO(joelhockey): Move implementation of HTMLFrameOwnerElement
 // setWidget/releaseWidget/ownedWidget that relates to plugins to here and
 // remove inheritance from PluginView to FrameViewBase.