Open GoogleCodeExporter opened 9 years ago
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
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
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
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
Attachments:
Can't reproduce on OSX with Safari and FireFox.
Original comment by georg.fritzsche
on 19 Mar 2010 at 1:06
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:
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
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
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
Original comment by georg.fritzsche
on 22 Mar 2010 at 12:40
Original comment by georg.fritzsche
on 24 Mar 2010 at 1:27
Original issue reported on code.google.com by
paulburt...@gmail.com
on 11 Mar 2010 at 4:31