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 79 matching lines @@
   DCHECK(!m_isDelayingLoadEvent);
 }
 
 DEFINE_TRACE(HTMLPlugInElement) {
   visitor->trace(m_imageLoader);
   visitor->trace(m_plugin);
   visitor->trace(m_persistedPlugin);
   HTMLFrameOwnerElement::trace(visitor);
 }
 
+void HTMLPlugInElement::dispatchBlurEvent(
+    Element* newFocusedElement,
+    WebFocusType type,
+    InputDeviceCapabilities* sourceCapabilities) {
+  Element::dispatchBlurEvent(newFocusedElement, type, sourceCapabilities);

[haraken, 2017/04/06 06:20:26]

Can we add a comment on why we want to call Element::dispatchBlurEvent first?

[joelhockey, 2017/04/06 06:28:39]

Done.  I hope my explanation is reasonable.  Feel free to suggest something
else.

[dcheng, 2017/04/06 06:28:49]

Thinking about this more, either ordering makes me nervous.

1) If we do the plugin first, and the plugin changes focus, we may
double-dispatch this blur event.

2) However, if we dispatch the DOM event first and the DOM event refocuses this
plugin, we will re-enter Document::setFocusedElement. I think this means we can
end up with plugin focus state in an inconsistent state: setFocused() will be
false on the plugin, since this runs after the re-entrant focus change.

In my mind, the safer alternative is to just have Document::setFocusedElement()
call this directly on the plugin (by checking if the focused element is a plugin
element and downcasting if so). What do you think of just doing this and not
using the override? This also lets us keep the original ordering of events.

[joelhockey, 2017/04/07 06:56:05]

You are right that it was possible for plugin to end up in an inconsistent
state. 

+  if (m_plugin)
+    m_plugin->setFocused(false, type);
+}
+
+void HTMLPlugInElement::dispatchFocusEvent(
+    Element* oldFocusedElement,
+    WebFocusType type,
+    InputDeviceCapabilities* sourceCapabilities) {
+  Element::dispatchFocusEvent(oldFocusedElement, type, sourceCapabilities);
+  if (m_plugin)
+    m_plugin->setFocused(true, type);
+}
+
 void HTMLPlugInElement::setPlugin(PluginView* plugin) {
   if (plugin == m_plugin)
     return;
 
   // Remove and dispose the old plugin if we had one.
   if (m_plugin) {
     document().view()->removePlugin(m_plugin);
     disposeWidgetSoon(m_plugin);
   }
   m_plugin = plugin;
@@ skipping 579 matching lines @@
 
 void HTMLPlugInElement::lazyReattachIfNeeded() {
   if (!useFallbackContent() && needsPluginUpdate() && layoutObject() &&
       !isImageType()) {
     lazyReattachIfAttached();
     setPersistedPlugin(nullptr);
   }
 }
 
 }  // namespace blink