IRC Log Viewer » #firebreath » 2013-07-04

IRC Nick Time (GMT-7) Message
ggg_ 01:07 Hii, please refer the link and help us
dougma 01:07 What does this have to do with firebreath?
i mean i see the FB_JSAPI_EVENT, but.... what the?
dougma 01:07 that macro defines a function called fire_CSharpEvent which you call from your plugin to raise events in the webpage.
is that what you want?
ggg_ 02:07 @dougma, my question is how to fire an event with arguments as VARIANT(not FB::variant) and IUnknown*..
dougma 02:07 you can't
you'll have to convert them to one of
ggg_ 02:07 So do you mean, custom events implementing EventArgs as argument can't be handled in firebreath
dougma 02:07 EventArgs?
i mean if you want to raise an event on the webpage, the parameters must be of types:
ggg_ 02:07 That's a .NET type of class which when implemented by a classs becomes a custom event
dougma 02:07 ok. so that's .net
firebreath isn't .net
ggg_ 02:07 Basically what am i doing is calling this EmptyEvent function in firebreath, (which later on fires the event) basically i'm using the fire_CSharp in firebreath only.
dougma 02:07 and where does EventArgs fit?
ggg_ 02:07 .NET...
so what if the argument is a COM equivalent of custom event like SEE the UPDATE here>>
ggg_ 03:07 Is boost::variant type supported as Listed in the Link u gave me
If it is so, then can VARIANT be converted to boost::variant
Thoys 03:07 hi there
Was wondering why FireBreath doesnt use the hosts from my host file
when I use FB::SimpleStreamHelper::AsyncGet with a hostname I've defined myself like it doesn't find the host
bor0 07:07 hi, I'm experiencing plugin crash in the following scenario: I have FB_JSAPI_EVENT(load, 0, ()); in my JSAPIAuto class. I use fire_load() in my constructor of my JSAPIAuto class, however the plugin crashes instantly. what I've noticed is actually that the plugin crashes when I try to addEventListener to it, any ideas?
basically I just want an onload event so that the javascript gets notified when plugin is ready. what's the easiest way to accomplish this?
Thoys 08:07 hi there
I was wondering if I can send a blob to a plugin function
taxilian 09:07 Thoys: not really, no
the best way we've found to send binary data to a plugin is base64 encoded as a string
simon_clark 10:07 quick question: is there any way to get the process ID of the browserhost from within a firebreath plugin instance?
taxilian 16:07 simon_clark: not through NPAPI. there might be way to do it with system APIs if you understand that the current process will either be the browsers or it will be owned by the browser's process
dougma 18:07 simon_clark: GetWindowThreadProcessId is your friend
simon_clark 18:07 dougma: thanks, I need it primarily on Mac though
I've got the plugin's PID, but can't figure out how to get the parent pid from that, or the pid of the browser host from firebreath
taxilian 18:07 firebreath doesn't know the browser's pid
it would find out the same way you do
there isn't anything in the browser apis to tell you that
actually, the browser vendors probably would prefer you couldn't find it
dougma 18:07 i didn't end up needing the pid on mac
so i don't know how to do that. :)
taxilian 18:07 this looks useful to you:
simon_clark 18:07 I'm running a firebreath NPAPI plugin in a node-webkit browser. It sometimes crashes but does not terminate properly, so the next time it launches, I need to hunt out old unterminated node-webkit browsers, and kill them
taxilian 19:07 err
wouldn't it be better to find out why it crashes and fix it?
and/or make your system more fault tolerant?
if you start killing browser-owned processes you're likely to get yourself blacklisted really fast
of course, having a plugin that crashes frequently will do that too...
dougma 19:07 yeah, but what's a node-webkit browser?
presumably this is not the desktop world?
simon_clark 19:07 it's a chromium fork that had node.js embedded
dougma 19:07 wow. sounds mental. :)
simon_clark 19:07 we're using it to run a signage app
taxilian 19:07 huh
simon_clark 19:07 agreed, fixing the root cause would be preferable, but it won't happen by Monday :)
dougma 19:07 probably you want to try to keep the process-killing logic outside your plugin in a shell script so you can iterate faster there. shell is better for killing processes surely?
taxilian 19:07 well, that's not the way I'd prefer to solve it, but getppid would probably be what you need
(which I found by googling 'find pid of parent process on mac ox', btw)
lol. mac os, not mac ox
simon_clark 19:07 damn, I went hunting on google, and missed it somehow
thanks, will take a look at it after dinner