Set plugin focus via element dispatch

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

 /**
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 1999 Antti Koivisto (koivisto@kde.org)
  *           (C) 2000 Stefan Schimanski (1Stein@gmx.de)
  * Copyright (C) 2004, 2005, 2006 Apple Computer, Inc.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.
@@ skipping 78 matching lines @@
   DCHECK(!m_pluginWrapper);  // cleared in detachLayoutTree()
   DCHECK(!m_isDelayingLoadEvent);
 }
 
 DEFINE_TRACE(HTMLPlugInElement) {
   visitor->trace(m_imageLoader);
   visitor->trace(m_persistedPlugin);
   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.
 void HTMLPlugInElement::setPlugin(PluginView* pluginView) {
   setWidget(pluginView);
 }
 
 PluginView* HTMLPlugInElement::releasePlugin() {
   FrameViewBase* plugin = releaseWidget();
   return plugin && plugin->isPluginView() ? toPluginView(plugin) : nullptr;
@@ skipping 549 matching lines @@
 
 void HTMLPlugInElement::lazyReattachIfNeeded() {
   if (!useFallbackContent() && needsPluginUpdate() && layoutObject() &&
       !isImageType()) {
     lazyReattachIfAttached();
     setPersistedPlugin(nullptr);
   }
 }
 
 }  // namespace blink