How can I get js invoked when my plugin is done initializing in IE?

[GoogleCodeExporter]

What steps will reproduce the problem?

I added this to the ctor of a plugin I wrote:

  registerEvent("onready");
  FireEvent("onready", FB::variant_list_of("ctor"));

And in the web page which uses the object:

  elt.innerHTML = '<object id="my-plugin"
classid="clsid:F9A809F1-8555-58AF-B07F-7102FF093C71" height=1
width=1></object>';

  Event.observe($('my-plugin'), "ready", function (msg) {
    doSomeStuff();
  });

But doSomeStuff() never happens.

doSomeStuff calls some methods on the plugin, and if I just call
doSomeStuff right after altering the HTML, I get errors that the methods
are not defined.

I know the event stuff is hooked up right, because if I call fireEvent from
one of my methods, my callbacks get invoked.

What's the best way to do this?  If it matters, although I'm working with
IE now, I'd like a solution which is portable to all common browsers and
platforms.

(I'm using prototype.js, but I've tried calling attachEvent and assigning
to plugin.onready, and I get the same lack of results.  And yes, this is a
simplified test case.  In my real app, I can't just put the <object> tag in
the html.)

What is the expected output? What do you see instead?

I want to run some code once my plugin is initialized.

What version of FireBreath are you using? On what operating system and
browsers?

I'm using IE8 on windows xp.  I'm not sure what version of FB I'm using;
someone else installed it, and I don't see any version file or other
indication in the top level of the source tree.

Please provide any additional information below.

Original issue reported on code.google.com by mhorow...@gmail.com on 5 May 2010 at 10:20

[GoogleCodeExporter]

I did some more experimentation: apparently the OLE callbacks which call
registerEvent* on JSAPI don't happen until after the ctor is run.

As a workaround, I did this:

// This gets used on Firefox

void MyPluginAPI::registerEventMethod(std::string name,
                                      FB::BrowserObjectAPI *event)
{
  JSAPI::registerEventMethod(name, event);

  if (name == "onready") {
    event->InvokeAsync("", FB::variant_list_of("registerEventMethod"));
  }
}

// This gets used on IE8

void MyPluginAPI::registerEventInterface(FB::BrowserObjectAPI *event)
{
  JSAPI::registerEventInterface(event);

  event->InvokeAsync("onready", FB::variant_list_of("registerEventInterface"));
}

And now I get callbacks when I want them.  It strikes me as odd that in js
immediately after adding the <object> to the dom, calling my own methods fails, 
but
the plumbing to set up event listeners is functional.  However, I have a 
workaround,
so I'm not going to dig too deeply into the mysteries of plugin initialization.

Original comment by mhorow...@gmail.com on 6 May 2010 at 4:18

[GoogleCodeExporter]

Plugin initialization etc. is not really defined anywhere. We could however 
introduce a generic "ready" event that 
doesn't depend on dynamic event registration from the plugin?

Original comment by georg.fritzsche on 10 May 2010 at 8:12

[GoogleCodeExporter]

We definitely should do something to fix this;  a generic ready event would 
probably
be a good idea.

Perhaps we could accept the name of the handler for such an event in a <param> 
tag

Original comment by taxilian on 10 May 2010 at 8:16

[GoogleCodeExporter]

I personally think a generic Ready event is an excellent idea. With the 
discrepancies
with how the browsers instantiate plug-ins it seems almost essential.

Original comment by jarom.lo...@gmail.com on 10 May 2010 at 8:22

[GoogleCodeExporter]

I'm glad to hear that you're considering implementing this.  After I 
implemented what
I describe above, I discovered that it doesn't work reliably on chrome on 
windows, or
on safari on macos, so I have to revert to polling, anyway.  Something reliable 
and
portable would make Firebreath even more valuable to me.

Thanks!

I'll also note that the problem is even worse than I could have possibly 
imagined. 
In my app, I have js like the code in my original post, and discovered that
sometimes, the jsapi glue initialization was delayed indefinitely.  I added a 
log in
the JSAPIAuto derived class ctor which uses BrowserHostWrapper::htmlLog.  Most 
of the
time, this log is printed when the plugin is instantiated.  However, about one 
time
in 20 on chrome for windows, I would check for $('my-plugin').valid immediately 
after
instantiating the object, and it was undefined.  In this case, the log would 
not be
printed.  But it wasn't a momentary delay.  In the inspector, when I evaluated
$('my-plugin'), even minutes later, I would see the log instantly.  Given this, 
I'm
not sure how to deterministically use the JSAPI in the plugin without polling 
which
not only tells me when the object becomes valid, but seems to actually cause the
browser to initialize the object.

Original comment by mhorow...@gmail.com on 11 May 2010 at 12:40

[GoogleCodeExporter]

taxilian wrote: "Perhaps we could accept the name of the handler for such an 
event in
a <param> tag"

Or via PluginConfig.cmake? It would probably not fix the *whole* initialization
fiasco though.

Original comment by georg.fritzsche on 11 May 2010 at 3:48

[GoogleCodeExporter]

Hmm. specifying something in PluginConfig.cmake is an option, but that creates a
"magic" javascript function that you just "have to know about", which I am
fundamentally opposed to.  It shouldn't be much (if at all) harder to do it 
from a
param tag than to specify something in PluginConfig.

Original comment by taxilian on 11 May 2010 at 3:59

[GoogleCodeExporter]

Original comment by taxilian on 9 Sep 2010 at 1:59

[GoogleCodeExporter]

I have added this feature to the http://code.google.com/r/taxilian-sharedptr/ 
branch; it will go into 1.2.  When you specify <param name="onload" 
value="function_name"> in the object tag, function_name() will be called when 
the plugin finishes initializing.

Original comment by taxilian on 11 Sep 2010 at 12:22

• Changed state: Fixed