IRC Log Viewer » #firebreath » 2010-11-03

IRC Nick Time (GMT-7) Message
larrow 00:11 irc test
DFUN 09:11 hello together
is there any example source code on how to use the StreamDataArrived event to save the data into a file?
taxilian 09:11 hmm. neilg_away might have one
BrowserStreams haven't yet been heavily used, so there aren't many examples yet
DFUN 09:11 hm, ok... thanks.
taxilian 09:11 sorry I can't help more :-/
DFUN 09:11 if neilg can offer any snippet, that would really help me
i'm not sure how to get the size of the data read so far
is it indicated by "getDataPosition"?
taxilian 09:11 hmm. you'll probably have to wait 'til neilg_away gets back :-( I don't know
have you checked the docs on the website?
DFUN 09:11 yes, of course I did
taxilian 09:11 just making sure =] you'd be surprised how many don't.
I didn't really expect you to be one of them, though; just verifying
DFUN 09:11 didn't find any example
and the source documentation did not help me at that point
taxilian 09:11 there is an example of using browserstreams in FBTestPlugin, but I don't know if it answers your question or not
learning to use that is on my to-do list for the next couple of weeks, but I haven't gotten there yet
DFUN 09:11 ah, ok... I was just thinking of some example code but couldn't remember where I found it
in FBTestPlugin there is a SimpleStream as example but it says "// see evt->data, evt->length, evt->progress, evt->dataPosition"
data is a protected member
so is length
that doesn't help
neilg_ 09:11 Did somebody call? :)
taxilian 09:11 you're now our resident streams expert
solve his problems, please :-P
DFUN 09:11 some impatient noob just a few minutes ago
neilg_ 09:11 Well, we're all screwed then. ;)
DFUN 09:11 I don't think so
now that you're here
neilg_ 09:11 Okay, let me just go back and read what you wanted - one sec
Aha, okay
kylehuff 09:11 don't fear mate; I will provide moral support while I eat funions and watch the telly..
DFUN 09:11 that sounds like an easy evening program
hope my evening gets that interesting
neilg_ 09:11 Funions! Oh wow, I haven't had those since I was a kid. =)
DFUN 09:11 <- never had funions... doesn't even know them
neilg_ 09:11 Anyway, about streams - you should know that onStreamDataArrived will probably get called multiple times as the browser downloads data for you
kylehuff 09:11 I even conjure up fond memories from childhood, I'm better at moral support than I thought..
neilg_ 09:11 It's just us Brits I think
DFUN 09:11 that's clear to me
neilg_ 09:11 So the FB::StreamDataArrivedEvent* which we'll call evt contains the necessary data
DFUN 09:11 also clear so far
neilg_ 09:11 evt->getData() returns a pointer to the data received since the last time onStreamDataArrived was called
evt->getDataPosition() returns how far into the stream we are
evt->getLength() returns how much data has been downloaded since the last time onStreamDataArrived was called
DFUN 09:11 aha
kylehuff 09:11 funions are british? I live in the US, funions abound here..
neilg_ 09:11 You could create your file either the first time onStreamDataArrived is called or when onStreamOpened is called
DFUN 09:11 sounds like FireBreath has done his part herewith
taxilian 09:11 that's mostly Nitro's handiwork. I may refactor BrowserStreams a bit for the next version to better use boost's pointers
and use some of neilg_'s fixes
but it's not bad =]
neilg_ 09:11 Really? I definitely had them as a kid. That and Monster Munch which is very similar :)
So hopefully that should get you started
DFUN 09:11 it will, thank you.
neilg_ 09:11 No problem. Glad I could help!
taxilian 09:11 thanks, neilg_
be back later, guys
neilg_ 09:11 Have fun!
kylehuff 09:11 never had the monster munch.. but it reminds me of a childhood insult which ends with the munch..
*with munch
neilg_ 09:11 They're very British - and very weird flavours too. Pickled Onion, Tomato - and those are just the ones I remember!
DFUN 09:11 just found out what funions are... quite as I expected, onion rings
kylehuff 09:11 the stuff they have now are actually quite grotesque.. they taste nothing like onions
anttix 09:11 Hello wizards.
Especially the C++ ones.
kylehuff 09:11 well, those ones you have refer to as "Mr. Wizards", as denoted by the "++" part..
DFUN 09:11 that must be the "fun" part of it
anttix 09:11 I have a question. It seems to me that functions returning ints do not work in JSAPIAuto
DFUN 09:11 that's a tough one. And enough for me for today (I'm just a questioner, too). See you guys
anttix 09:11 Eg: this API fails for me in Firefox: class TestAPI : JSAPIAuto { TestAPI() {registerProperty("bug", make_property(this, &TestAPI::GetBug)); } size_t GetBug() { return 1; }}
well, I just wrote it from the top of my head now, but the problem is that when I make an int type property in JSAPIAuto class, Firefox will not see it.
neilg_ 09:11 Possibly because you're using size_t rather than int?
anttix 09:11 Well, make_property should fail then, shouldn't it?
neilg_: I'll try with "real" int
neilg_ 09:11 I'm not sure what it would do in that case
anttix 09:11 What makes me wonder is that FB::JSArray Doesn't work either.
It might be buggy though, I don't see any classes in FB using it.
neilg_ 09:11 Depending on your compiler size_t is probably a 64-bit value and int is probably 32-bit so that's what makes me wonder
You're right though, it could be a bug - I haven't used the JSAPI functionality in FB at all yet
anttix 09:11 neilg_: true, I compile it to 64bit code currently
neilg_ 09:11 Good luck! I have to go to a meeting, bbl
anttix 09:11 neilg_: You were right. size_t-s do not work properly.
size_t-s are not wrapped properly for 64bit I presume then.
which makes FB:JSArray unusable, since it returns length as size_t
I don't know if they work for 32bit code though.
taxilian 09:11 anttix: which version of firebreath are you using?
ahh, the JSArray reference gives you away
you're using an old version
upgrade =]
and good to see you again =] it's been awhile
anttix 09:11 taxilian: Yeah, I've been busy :)
taxilian: I'll do hg pull right away
taxilian 09:11 how long has it been since you last updated?
are you on a 1.3 or later branch and it still doesn't work?
what are you using FB::JSArray for, then?
anttix 09:11 taxilian: I think I'm using the 1.3
taxilian: Well, I was inheriting from it.
taxilian 09:11 it changed in 1.3; you know that?
anttix 09:11 taxilian: I am creating an array with ToString to JSON :P
taxilian 09:11 you'll have a hard time convincing me that's a better idea than returning a VariantMap and using browser functions to convert it to json
anttix 09:11 taxilian: Ah, I'm on latest trunk though.
taxilian 09:11 but in 1.4 I have utility classes to do that for the most part
anttix 09:11 taxilian: Well .....
taxilian: I'm emulating a broken behaviour :P
taxilian 09:11 ok; well, FB::JSArray now is a wrapper for a javascript array that helps you access a live array
rather than being a fake array like it was before
so I'm surprised it works for you at all
anttix 09:11 taxilian: I have an emulation mode of another plugin that used to return JSON strings (bad design decision, I know, this wasn't written by me)
taxilian 09:11 the old JSArray is now JSFakeArray
dstarin: welcome
anttix 09:11 taxilian: the problem is that there is a name conflict
taxilian: So I'm returning an object that behaves as a JSON string AND as an array. Coool, heh?!
dstarin 09:11 taxilian: thanks
taxilian 09:11 anttix: if you're interested, I have jsoncpp as a firebreath library in 1.4. I also have a function (not yet in the repo, but I'll give it to you) that converts a variant to json using it
anttix: are you inheriting from FB::JSFakeArray or FB::JSArray?
anttix 09:11 taxilian: I could differentiate from plugin mime type though, but is seems it's not implemented for NPAPI. I have looked at it, but haven't got into fixing this.
taxilian 09:11 because FB::JSArray changed in 1.3
anttix 09:11 taxilian: FB::JSArray
dstarin 09:11 taxilian: you mentioned in google groups a paper on plugin architecture that you wrote, I'd be interested in reading it..
taxilian 09:11 anttix: multiple mime type support is planned for 1.4
anttix 09:11 taxilian: That's the first that came up when I did grep -ri Array :P
taxilian 09:11 dstarin: hang on, I'll get you the link. please don't distribute it
anttix 09:11 taxilian: cool :)
taxilian: then we can get rid of our own hacks that sort-of implement it.
taxilian 09:11 anttix: it used to work, but I didn't think anyone was using it so I moved it because the naming didn't make sense
dstarin 09:11 taxilian: for sure...
anttix 09:11 taxilian: Don't worry, I started using it today. I'll look into the FakeArray class
taxilian 09:11 dstarin:
anttix: ok; there have also been changes recently in the way that numeric type conversion works. If size_t really isn't working we'll want to let cygmatic (Georg) know. he's probably the best to track that one down
int previously wasn't allowed because on IE we get a long, so to typecast to int could cause loss of data
but we're now using boost::numeric_cast, so they should all work
anttix 09:11 well, size_t doesn't I can confirm that.
taxilian 09:11 dstarin: you'll need a login for the wiki to get to that
good to know
can you create an issue?
anttix 09:11 taxilian: You mean that class? FakeJsArray?
taxilian 09:11 yeah
I thought I renamed it in 1.3
guess I renamed it in 1.4
nevermind =] just be aware it will change
dstarin: let me know what you think
anttix 09:11 taxilian: I will, dont worry :)
dstarin 09:11 taxilian: will do, thanks!
taxilian 10:11 anttix: try adding a line for size_t in the method on line 640 of variant.h
anttix 10:11 taxilian: I'll try it out and see what happens.
dstarin 10:11 taxilian: I'm looking to make my extension that depends on c++ native code browser independent. It works great in Firefox with XPCOM/IDL right now. Is firebreath the right platform to build on?
taxilian 10:11 well, it's probably the easiest way to get cross-platform C++ code into the browsers
but you'll have to write the extension part seperately
dstarin 10:11 taxilian: yea thats what i figured... so ill write unique extension code for each browser to sit on top of the plugin
i know chrome (google) lets you specify what your plugin can only be run local
does firefox?
taxilian 10:11 I don't know of a way to control where a plugin can be run from, though extensions may be controllable
including on Chrome
anttix 10:11 Well, You can package NPAPI plugins into XPI extension packages for Firefox.
If that's what You asked for.
And there can be platform specific directories
and the plugin is disabled properly when You disable the extension from extension manager
so it's easy to distribute Your cross-browser plugin along with a Firefox extension.
dstarin 10:11 anttix: cool
taxilian 10:11 dstarin: Make sure you are clear on the difference between an extension and a plugin
a plugin can be packaged inside an extension
but they are very different
anttix 10:11 I have a CMake target to test my FireBreath plugin and FF extension in one go.
dstarin 10:11 antix: yea, i feel like that is the direction im going...
taxilian: i think i get the difference, I just don't see a better was of writing a cross-browser extension other than using firebreath to write the underlying npapi plugin and then unique extension code for each browser
*better way
anttix 10:11
dstarin: You are correct.
dstarin: it depends on what Your extension is doing though
dstarin: look at the NPAPI spec, basically it's handling <object> tags in HTML
dstarin 10:11 anttix: write but in my case, i cant just be sandboxed like google native client
anttix 10:11 dstarin: everything else, well, You are out of luck
dstarin: so if You want a JavaScript API to do cool things on web pages, then plugin is a right way to go
dstarin: but if You need to modify the browser itself, add something to toolbar etc. then it needs to be an extension.
taxilian 10:11 on the other hand, many people have used FireBreath with an extension
anttix 10:11 True, I do ;)
taxilian 10:11 they use the extension to embed the plugin and then make calls to it
dstarin 10:11 right, thats what im looking to do
taxilian 10:11 let me know how it works =]
anttix 10:11 taxilian: Adding size_t to variant.h didn't make a difference.
taxilian 10:11 hmm. interesting
I'll have to look at it
if you could create an issue, that'll make sure I don't forget
dstarin 10:11 taxilian: yes of course, and keep up the good work
anttix 10:11 taxilian:
taxilian: wrote the code in issue from the top of my head though, it may not compile ;)
taxilian 10:11 thanks
that should be good enough
I've used firebreath ac ouple of times, so I can rpobably figure it out
anttix 11:11 taxilian: :D
anttix 12:11 Hi! It seems that JSAPIAuto::GetProperty(int) is not called from Firefox, at least not when out-of-process plugins are used.
So I guess JSFakeArray will not work anyway :(
taxilian 13:11 anttix: you can use it
if getProperty(int) isn't getting called, check to see if it is getting called as a string
anttix 13:11 taxilian: I added printf-s to both GetProperty(int) and GetProperty(string) in JSAPIAuto.cpp
taxilian 13:11 what browser?
anttix 13:11 taxilian: neither of them were called by FF
taxilian: FF 3.6.12 out-of-process plugins enabled.
taxilian 13:11 then something else is wrong. maybe FF 3.6.12 with OOPP is broken
what JS are you using?
anttix 13:11 taxilian: something like var a = obj.getBlah(); alert(a.length); alert(a[0]);
taxilian 13:11 and getBlah returns a JSAPIAuto object?
anttix 13:11 taxilian: Yep
taxilian 13:11 ooh, wait… does HasProperty(int) get called?
I bet it's calling HasProperty, maybe even with the int as a string
and HasProperty is returning false
anttix 13:11 taxilian: maybe
taxilian: I will check it out
taxilian 13:11 I bet that's it
If I win, you make an update to a wiki page of your choice. If I lose, I'll give you free advice on anything plugin-related. ;-)
anttix 13:11 taxilian: Well it is calling HasProperty, yeah, but the string version and in an interesting way: HasProperty('')
I'll return true for an empty string and see what happens then.
taxilian 13:11 is that for [0]?
try it for [1]
I think I've seen this behavior in webkit before
anttix 13:11 taxilian: no difference
taxilian 13:11 really? ok, that's gotta be a firefox bug, then
anttix 13:11 taxilian: I'll test with chromium in a second
taxilian 13:11 you could also check what it actually sends in NPJavascriptObject
anttix 13:11 taxilian: chromium acts exactly the same
taxilian: I will check what happens if I disable out-of-process plugins in FF
taxilian 13:11 hmm . I guess it could be a firebreath bug
it's been awhile since I tested that
anttix 13:11 taxilian: FF IPC mode didn't make any difference.
taxilian 13:11 ok, something else weird is going on here, then
anttix 13:11 taxilian: I'll look into NPJavaScriptObject for a moment
taxilian 13:11 wait a sec...
ok, did you try returning true to the ""?
anttix: line 122 of NPJavascriptObject.cpp; I'm not sure why I'm not checking IsStringIdentifier here
but my bet is that previous versions didn't care
anttix 13:11 taxilian: Yep, I was reading that code too
taxilian 13:11 but at some recent point Firefox started calling HasProperty for integer values
not sure why that would change
but it's the only thing that makes sense, since I'm 100% confident that this worked last time I tried, and I don't think this has changed
anttix 13:11 taxilian:
taxilian: this did the trick, HasProperty(int) is called now
taxilian: I'll have to go home now, I'll push this patch to FB tree later, when I get back. If it looks OK for You though.
ok, gotta go. seeya
anttix 15:11 taxilian: If You have a minute, I'd like to have a word with You about mimeType passing. Nothing urgent though ;)
taxilian 16:11 anttix: I'm here now
and I'm quite interested in what you have to say, since I'm still debating some of the specifics of how that will be implemented
anttix 16:11 taxilian: Well I have a patch to propose
taxilian 16:11 ok
we'll see how close it is to what I'm already planning =]
anttix 16:11 taxilian:
taxilian: well, it's just for NPAPI right now, because that's where I needed it ;)
taxilian 16:11 no, I will not accept that patch
let me tell you why
anttix 16:11 taxilian: but I think it's a correct way to do it since it's not available during plugin object construction.
taxilian 16:11 it is, actually
anttix 16:11 taxilian: from where?
taxilian 16:11 when the plugin object is created, pluginCore itself, we can pass in the mimetype
hang on, let me look
however, I think it is very important that we pass in the mimetype to the factory when requesting the plugincore object
that way you can optionally return a completely different plugincore object for different mime types
anttix 16:11 taxilian: True, but I don't think it's possible :(
taxilian 16:11 I will happily prove otherwise =]
look at line 158 of NpapiPluginModule_NPP.cpp
anttix 16:11 taxilian: as far as I understand the npapi init function that this is passed to
taxilian 16:11 that's how it gets passed currently
but that's in our code
when we create the NpapiPlugin, which contains the PluginCore object, we can add the mimetype to the constructor
which can then pass it to the PluginCore as it is created
that's actually the easy part
the hard part is doing it on ActiveX
anttix 16:11 Well, I'm not very familiar with ActiveX
taxilian 16:11 yeah
me neither :-P
but if you want to code that up in the dev repo, I'll happily accept that
I've been planning for it
just make sure you put it in
anttix 16:11 well, I might do that for NPAPI
taxilian 16:11 yeah
so the real truick
anttix 16:11 taxilian: is that different from ?
taxilian 16:11 is going to be coming up with a good way in CMake to specify multiple mime types to register for
dev.firebreath is the development repo
it's currently where 1.4 is
anttix 16:11 taxilian: ok, so I pushed my last change to wrong repo :S
taxilian 16:11 the trunk repo is the stable branch; only bugfixes go into there, no features
actually, that's where I wanted it
because it is actually a bugfix
and not a dangerous one
this one is a feature add
someday I'll switch to git and we can use branches and it will be a lot cleaner
anttix 16:11 taxilian: Ok. Cool. Thanx for explaining the new layout.
taxilian 16:11 yeah, sorry I'd forgotten you haven't been around for awhile so you didn't so
didn't know
anttix 16:11 taxilian: ok, I'll look into the mime type passing code a bit more in detail. Do You think we should remove the mimetype argument from npapi plugin init function too? The argument is not used.
taxilian 16:11 yeah, probably so
for clarity
anttix 16:11 ok, I'll cook something and bug You if I get something in sort-of shape.
taxilian 16:11 cool. I could probably do it myself fairly quickly, but it's good to have other people getting their hands on that part of the codebase
and I probably won't get to it for awhile =]
besides, I've got to figure out the ActiveX side, and that's a *lot* harder
anttix 16:11 taxilian: yeah, I know :(
taxilian: when thinking about multi-mime plugins it might be cool to implement multiple-GUID ActiveX too.
taxilian 16:11 you're pretty decent with cmake, right?
that's how we'll have to do it
I don't see another way
activex even when used with a mimetype is instantiated by GUID
anttix 16:11 taxilian: Well, I know my way around, but Kalev is lot better than me on this ;)
taxilian 16:11 so the only way to get the mimetype is to find out which GUID was used to instantiate it and do a lookup in a table
what would really help is someone who could create a set of macros or whatnot for specifying additional mimetypes that should be supported
itt will need to generate a small amount of C++ code and a few different formattted strings for the plist and npapi mimetype strings
anttix 16:11 taxilian: well, I can't promise You anything, but we would LOVE to get rid of our ugly patches, so I might look into it.
taxilian: I know all the nitty details, we are producing multi-mime plugins with some very ugly hacks right now
taxilian 16:11 you know me; I'm happy to help you with your goal to get rid of your ugly patches, I just can't do all the legwork myself =]
are you guys using activex at all?
can't remember
anttix 16:11 taxilian: yes, and we have two-guid control.
taxilian 16:11 really? how did you implement that?
anttix 16:11 taxilian: with another hack :P
taxilian 16:11 that I guessed =]
wondering what hack you used
and if it could be tweaked into something less hackish
anttix 16:11
Not pretty :(
It includes another set of RC files, that I believe were hand crafted
I should of known, I did work on it, but I can't remember, because it was ages ago and was implemented as a quick-n-dirty-hack, as usual :P
taxilian 16:11 hehe
in this patch I'm not seeing how you got a second instance of FBControl bound to a different GUID
the RC changes will only help with firefox
incidently, as of 1.3.0 (and of course in 1.4 from dev), you can copy anything from the gen_templates dir into your plugin dir and it will use that instead of the default
anttix 16:11 With an IDL like this I presume:
taxilian 16:11 ooh.. I hadn't realized that your plugin was in source control
open source, I mean
that's cool
anttix 16:11 taxilian: I prefer patches ;) It's the Linux packager way, get upstream sources, patch them, maintain patches.
taxilian: this way You get new stuff when upstream changes ;)
taxilian: and of-course send as many patches to upstream as You can.
taxilian 16:11 what I mean is that you don't have to create your own .rc, .rgs, .idl tools, you can use the built-in FireBreath ones, just override the default file
no need to merge
patches are good and all, but when you don't have to change the trunk and you can customize it all in your own plugin, it's less work to maintain
anttix 16:11 taxilian: well I haven't looked into this function yet. I sure will someday ;)
taxilian 16:11 I just barely added it
it's the only change between RC3 and 1.3.0 release =]
so I'm just letting you know it's there, so when we remove the need to be hacky you can use it
anttix 16:11 taxilian: thanx.
taxilian: Ok. I gotta go to bed now, It's getting late on this side of the globe.
taxilian: Happy hacking.
taxilian 16:11 ok. thanks for dropping in
drop in more often =]
anttix 16:11 taxilian: Yeah, it's been cool around here, maybe I will :)
taxilian 16:11 sleep well and wake
taxilian 20:11 nirvdrum: do you think it might be possible to make an ActiveX control without a .idl file, or does the .TLB have to be compiled in all the time?
nirvdrum 20:11 There's probably a way to get around that if you're crafty enough. I haven't the slightest idea how you'd go about it.
taxilian 20:11 fair enough
I think I have the multiple mimetype on activex problem figured out
but implementing it completely will be a bit of a pain
nirvdrum 20:11 Ultimately I think it's just a UUID => method definition. So, if you could get the entry points in the DLL correct, I guess you could theoretically get around it.
I'd imagine Georg would have more to say about that.
taxilian 20:11 that's half the issue
the other half is the class registration
how the system finds your plugin
and how we know to register that CLSID for this dll
it'll be a bit trickyish
nirvdrum 20:11 Well that registration is pretty standard. It'd be a bitch, but you could generate the .reg file yourself.