Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
Original comment by taxilian
on 9 Sep 2010 at 1:59
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
Original issue reported on code.google.com by
mhorow...@gmail.com
on 5 May 2010 at 10:20