Firing event kills firefox

[GoogleCodeExporter]

I have a plugin which creates a thread in it's API object which it polls a
device for data. When data is available the thread calls
BrowserHostWrapper::ScheduleAsyncCall (on the host passed to the API object
constructor) to get back to the browser/plugin thread, where FireEvent is
then called to pass the available data to some javascript (though reading
the code it seems FireEvent may take care of threading anyway? but that's
another matter...). This works OK initially, but if I refresh the page then
suddenly the throw statement in NPObjectAPI::Invoke gets called. The method
name is empty (i.e. default) and the args look like the ones I pass to
FireEvent. I tried modifying NPObjectAPI::Invoke to set retVal to
void/undefined instead of throwing the exception and sure enough that stops
firefox from dying, but my plugins event isn't fired. If I then refresh the
page again the event works again - it seems to work on every other refresh.

This happens with firefox 3.6 on both windows vista x86 and linux x86_64,
and I'm using the current firebreath head/tip/whatever-mercurial-calls-it.
I'll try to put together a small test case soon as my plugin requires the
windows DDK to build and a bluetooth device to be of any use, but I wanted
to post this now and see if anyone has any ideas about what might be happening.

I apologise if this is something obvious I'm missing - I don't know very
much about NPAPI/plugin development. Also I apologise if this isn't the
right place to put this. I see there's a -dev mailing list, perhaps there
should be a -users one too?

Original issue reported on code.google.com by paulburt...@gmail.com on 11 Mar 2010 at 4:31

[GoogleCodeExporter]

See what happens if you just call FireEvent directly; as you surmised, it does 
take
care of the threading itself.

if you can recreate the issue with code that we can build and debug that will 
help a
lot in tracking down the cause

Original comment by taxilian on 11 Mar 2010 at 4:37

• Changed state: Accepted

[GoogleCodeExporter]

Also, at present the -dev list doubles as a users mailing list; we may consider
changing that at some point, but it's pretty low traffic so far and generally 
the
devs and the users are thus able to learn from each other.  When you get 
additional
information, that would be a good place to put the conversation.

Original comment by taxilian on 11 Mar 2010 at 4:38

[GoogleCodeExporter]

OK, here's a small test project. I've only tried it on linux but I think I 
included
everything it should need for windows too (if not it should be pretty small 
fixes
required). Essentially here is a thread which fires off an event every 10ms. If 
you
open test.html in firefox then close the tab, refresh, load some other page etc 
then
this happens:

paul@paul-desktop:/usr/lib/firefox-3.6$ firefox -P test -no-remote
~/path/to/firebreath/projects/ThreadTestPlugin/test.html 
terminate called after throwing an instance of 'FB::script_error'
  what():  
Aborted

Original comment by paulburt...@gmail.com on 11 Mar 2010 at 5:13

[GoogleCodeExporter]

It's 5:14am. Therefore I'm allowed to forget to attach things.

Original comment by paulburt...@gmail.com on 11 Mar 2010 at 5:14

[GoogleCodeExporter]

Can't reproduce on OSX with Safari and FireFox.

Original comment by georg.fritzsche on 19 Mar 2010 at 1:06

[GoogleCodeExporter]

This seems to happen much more reliably when the javascript triggered by the 
event
does something with the plugin. This updated test makes the event fire every 
100ms
rather than every 10ms (mostly because that matches my real plugin after I've
modified it a little). In the javascript the only change is that it sets and
retrieves a property of the plugin. Now when I open test.html in firefox (3.6 on
Linux) the data on the page will update as expected (4th number is a counter), 
but
refreshing the page will consistently throw the FB::script_error and kill 
firefox.

Original comment by paulburt...@gmail.com on 20 Mar 2010 at 3:13

Attachments:

• ThreadTestPlugin.tar.gz

[GoogleCodeExporter]

Indeed, i can reproduce with that on OSX10.6/FF3.6. Looking into it.

Original comment by georg.fritzsche on 20 Mar 2010 at 4:25

[GoogleCodeExporter]

While we still have to look into a background issue, your problematic case 
should be
fixed. Can you confirm?

Note that your thread starts firing before the scriptable object is even 
returned to
the browser - a possible solution might be a "start" method that the script 
calls?

Original comment by georg.fritzsche on 21 Mar 2010 at 4:00

[GoogleCodeExporter]

Yes, that fixes it, thanks. That's a good point about the event firing before 
the
object is returned, and something I hadn't thought about when writing the test 
case,
but for my real plugin it's not a problem as the event won't start firing 
straight
away anyway.

Original comment by paulburt...@gmail.com on 21 Mar 2010 at 4:54

[GoogleCodeExporter]

Original comment by georg.fritzsche on 22 Mar 2010 at 12:40

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by georg.fritzsche on 24 Mar 2010 at 1:27