Open GoogleCodeExporter opened 9 years ago
This is likely a bug in opera; I don't have time in the near future to look
into it.
Does someone else?
If someone can figure out what is happening, I may be able to help get the
resolution.
Original comment by taxilian
on 16 Feb 2010 at 5:58
[deleted comment]
Original comment by georg.fritzsche
on 27 Feb 2010 at 8:40
Opera gives us an entry for NPN_PluginThreadAsyncCall in the NPN function
table, but
nothing happens when it is called.
A simple test to reproduce that is:
void foo(void* p) { assert(false); }
void MyPluginAPI::foo() { m_host->ScheduleAsyncCall(&::foo, 0); }
Original comment by georg.fritzsche
on 27 Feb 2010 at 10:07
I pushed a experimental workaround, would be good if someone else then me
tested it.
Note that i had still issues when registering events in document.onload while
later
registrations work fine. I am still trying to figure out what should be done in
Opera
in the first case.
Original comment by georg.fritzsche
on 1 Mar 2010 at 4:09
There was no response in the Opera forums, so i issued a bug report for it.
The problem seems to be that plugins simply are not loaded before the
document.onload-event.
Original comment by georg.fritzsche
on 9 Mar 2010 at 7:10
Having delt with the Opera development team in the past I can tell you the way
they initialize plug-ins is quite
different from other browsers. The Opera browser does much of the
initialization of the plug-in asynchronously
and in my experience the way they do their discovery of methods and such works
best when fully defined at
compile time. Things like dynamic properties and methods are suspect at best
within Opera.
I will dig through my e-mails and see if I can find the contact information for
their people that I worked with.
-Jarom
Original comment by jarom%ti...@gtempaccount.com
on 9 Mar 2010 at 9:46
The person I worked with in the past was:
Ola P. Kleiven
Site Compatibility, Opera Software.
"Ola P. Kleiven" <olak@opera.com>
Cheers,
Jarom
Original comment by jarom%ti...@gtempaccount.com
on 9 Mar 2010 at 9:49
Thank you, i'll try that then if the bug report doesn't get me feedback.
Original comment by georg.fritzsche
on 9 Mar 2010 at 10:11
The initialization order in Opera is "by design" - apparently they intend to
conform
to the de-facto standard set by other browsers, but are not there yet.
Until then, scripts can use workarounds like polling for a plugin property
until its
not undefined anymore.
(Thus closing as fixed as far as we can fix it)
Original comment by georg.fritzsche
on 16 Mar 2010 at 10:32
We noticed that version 1.0rc3 does not really work as it is supposed to. Even
in
Firefox.
We used FBControl.htm for testing. Calling plugin.testEvent function always
throws
error. Basically this function is undefined.
Rafał Chłodnicki
Core QA, Opera Software ASA
Original comment by rch...@gmail.com
on 23 Mar 2010 at 7:34
We will be releasing 1.0 from source control as soon as I have time to do so.
Please
use the latest from source control until then.
Sorry for the inconvenience.
Original comment by taxilian
on 23 Mar 2010 at 7:49
Tried cloning repository and building from it but that does not make much
difference
unfortunately.
First clicked "set onload (ff)" then "Fire onload" and I get error
"plugin.testEvent
is not a function" (in Firefox).
Original comment by rch...@gmail.com
on 23 Mar 2010 at 8:57
Okay; please create a new issue for this, indicate the OS and browser you are
using,
and we will look at it. Most likely something was changed in the test project
and
FBControl.h needs to be updated.
The feature itself works, but please create an issue for the problem you're
experiencing with that test tool
Original comment by taxilian
on 23 Mar 2010 at 9:03
Filed http://code.google.com/p/firebreath/issues/detail?id=35
Original comment by rch...@gmail.com
on 23 Mar 2010 at 9:48
Original issue reported on code.google.com by
vgzhzf...@googlemail.com
on 16 Feb 2010 at 5:46