Emit error events if the loading of an object element failed

components/plugins/renderer/loadable_plugin_placeholder.cc

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "components/plugins/renderer/loadable_plugin_placeholder.h"
 
 #include <memory>
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
@@ skipping 53 matching lines @@
     : PluginPlaceholderBase(render_frame, frame, params, html_data),
       heuristic_run_before_(false),
       is_blocked_for_tinyness_(false),
       is_blocked_for_background_tab_(false),
       is_blocked_for_prerendering_(false),
       is_blocked_for_power_saver_poster_(false),
       power_saver_enabled_(false),
       premade_throttler_(nullptr),
       allow_loading_(false),
       finished_loading_(false),
-      weak_factory_(this) {}
+      weak_factory_(this) {
+      plugin()->markAsPlaceholder();

[Bernhard Bauer, 2017/03/08 14:03:14]

If there is a way that the plugin might run eventually (e.g. click-to-play), we
should _not_ emit an error event. It is by design that the page can't
distinguish a blocked plugin from one that just takes a reeeallly long time to
load.

OTOH, if we know that the plugin will never load (e.g. enterprise policy), then
yeah, we can notify the page. Tommy, WDYT?

[George Joseph, 2017/03/08 14:45:57]

Hello Bernhard,

Thanks for reviewing the change.The original bug was raised because no events
were being fired when a plugin could not be loaded.In the added test case , that
is the scenario I have replicated - a mimetype for which a Plugin cannot be
loaded has been added.

Currently, Firefox does fire an error event, if a plugin for a mimetype cannot
be loaded. Also , it does fire an error event if a  plugin is blocked (even if a
plugin can be created for the mimetype). On unblocking the plugin , firefox does
not fire a load    event on the object.

My debugging so far has revealed that the ChromePluginPlaceholder is
instantiated only when a plugin cannot be created from the existing mimetype
registry, this is so that a plugin object will always be created irrespective of
whether the plugin is supported or not so that a Widget always gets instantiated
(even if the mimetype is not supported) - I am happy to be corrected on this.

Please note that I could not add code to send load events, because ideally, once
a plugin is loaded I would think that it is the plugins responsibility to fire
events if event handlers are registered.It can be done in the HTMLObjectElement
, but then if a plugin fires its load handler, after a load it would result in
mutilple events for one load.For the purpose of the bug, I think the onus of
dispatching load events should be on the plugin.



Do let me know your thoughts,
Thanks,
George.

[Bernhard Bauer, 2017/03/08 18:01:13]

Okay, being consistent with Firefox is probably a good idea, but I'd like to
make sure everyone is okay with that change, as the existing behavior is quite
deliberate. +Rachel to confirm (should we loop a PM in as well?)
Unfortunately that's not how things work. Flash (which really is the only plugin
at this point) does not fire such an event AFAIK, and I don't think that is
likely to change in the future. This is again why I prefer the current behavior
(at least for plugins that might load at some point).

[George Joseph, 2017/03/08 21:20:42]

Hello Tommycli and Berhhard,
Thanks for getting back to me. Just to clarify, in the case of throttling the
plugin to be loaded later,Firefox on
not loading the plugin does fire the error event despite being capable of
rendering the 
content i,e; if the acrobat plugin is stopped, it does fire the error event.

Since this was marked as an interop Issue I implemented a change. Maybe I could
add a few checks to see if 
the plugin is throttled purposely before setting the placeholder flag.

Could you give me a scenario where I can replicate throttling the plugin for
later loading,
so that I can trace the code flow and check the exact states available to 
loadable_plugin_placeholder.cc to take that decision.

From what I have understood today from these conversations,I would think that
nonloadable_plugin_placeholder.cc 
should be loaded when a non loadable plugin object is in the app, however, this
does not seem to be 
created currently.

Do let me know your thoughts 
Thanks,
George.

+}
 
 LoadablePluginPlaceholder::~LoadablePluginPlaceholder() {
 }
 
 void LoadablePluginPlaceholder::MarkPluginEssential(
     PluginInstanceThrottler::PowerSaverUnthrottleMethod method) {
   if (!power_saver_enabled_)
     return;
 
   power_saver_enabled_ = false;
@@ skipping 279 matching lines @@
   return identifier_;
 }
 
 bool LoadablePluginPlaceholder::LoadingBlocked() const {
   DCHECK(allow_loading_);
   return is_blocked_for_tinyness_ || is_blocked_for_background_tab_ ||
          is_blocked_for_power_saver_poster_ || is_blocked_for_prerendering_;
 }
 
 }  // namespace plugins