IRC Log Viewer » #firebreath » 2010-12-27

IRC Nick Time (GMT-7) Message
WarGloom 00:12 current version from git: tests passed, but FBTestPlugin crashed in chromium and google-chrome on test.html
kalev 00:12 WarGloom: I guess taxilian is already sound asleep
try to get a backtrace and post it in a bug report; I'm sure taxilian is interested in regressions
WarGloom 00:12 yes, thank, I'll do
WarGloom 01:12 what the proper way to call javascript callback (wich will show dialog) and wait result of user input?
taxilian 03:12 WarGloom: I'm not honestly sure if that'll even work safely (sometimes tricks like that seem to cause some pretty major-ish problems) but you'd just call Invoke
WarGloom 03:12 I wrote js callback
and call Invoke
google-chrome and chromium show the dialog, and I can get password, but firefox blocked
c++ code вызывающий js
taxilian 04:12 reading...
kalev 04:12 WarGloom: is this running in a separate thread?
taxilian 04:12 ok, you're using an asynchronous password dialog
hmm, I see, so you're polling...
WarGloom 04:12 yes
taxilian 04:12 kalev: definitely seems to be running in a seperate thread
WarGloom 04:12 yes, ofcouse thread calling callback != main thread
kalev 04:12 does Invoke get scheduled back to the main thread?
taxilian 04:12 yes
and uses a signal to wait for the call to complete
and returns the result
I'm rather proud of it, actually :-P
ok, first problem that I'm seeing is that obj.convert_cast<FB::JSObjectPtr> is going to throw an exception if it's not that type
I guess you're checking that, though
then just reusing obj; I see
honestly, if it were me I wouldn't do it this way; I'd instead have javascript call back to the plugin when it has the password
but I'm not sure why this wouldn't work
when you say "firefox blocked", what exactly is happening?
(fyi, kalev, he's answering me on another channel in Russian, since he can explain faster there and I need to go back to bed)
4am here...
kalev 04:12 sure
hey, you are too addicted to Firebreath if you wake up 4am in the morning just to check the channel :)
taxilian 04:12 lol. well, I won't argue that I'm too addicted to FB, but I actually got up to see my wife off
she's driving a friend to the airport
the addicted part comes in that I checked my email and the chatroom on my way back to bed...
WarGloom 04:12 long long way to bed :)
kalev 04:12 hehe
taxilian 04:12 hmm. it sounds like despite scheduling the call on the main thread it isn't getting run...
might be a bug in the browser's NPN_PluginThreadAsyncCall :-(
kalev 04:12 I'm doing similar callbacks but directly on the main thread
taxilian 04:12 yeah, directly on the main thread it's never a probelm
only when calling from a second thread
the problem is that since it waits for a signal to fire, if the callback doesn't ever get called it can be a bit of a problem =]
kalev 04:12 yeah
taxilian 04:12 hmm. I should definitely tweak that to have a timeout, just in case
WarGloom 04:12 o, I can check if callback from main thread will work
taxilian 04:12 meh, that'll work fine
that's easy
WarGloom: try pulling from git:// master
see if it fixes your chromium crash
the problem, btw, is a browser bug
one more to add to my ever-growing list
WarGloom 04:12 yes, this patch fix chromium
taxilian 04:12 then I'll push it to master
WarGloom 04:12 wait
FB_GitHubBot 04:12 FireBreath: master Richard Bateman * 2b80107 (4 files in 3 dirs): Merge branch 'master' of
FireBreath: master Richard Bateman * 9967cc2 (1 files in 1 dirs): Attempted fix for issue 123 on linux chromium
FireBreath: master commits d3c93b3...9967cc2 -
taxilian 04:12 too late :-P. whats wrong?
oh, crap. hang on
how did that get in there?? grrr...
WarGloom 04:12 crash
in another point
FB_GitHubBot 04:12 FireBreath: master Richard Bateman * 1c93351 (1 files in 1 dirs): Attempted fix for issue 123 on linux chromium -
taxilian 04:12 WarGloom: does this happen on any other browsers? can you tell what is being called on the plugin when it crashes?
oh, this seems to be yours that is crashing, no? not FBTestPlugin
WarGloom 04:12 да
taxilian 04:12 you're calling a function "Count" somewhere?
WarGloom 04:12 да, возможно
taxilian 04:12 on an object that you passed back in from javascript into your plugin that originally came from your plugin?
WarGloom 04:12 подозреваю что да, сейчас проверю
я в ту часть кода давно не залезал...
taxilian 04:12 you know, I needed that word yesterday and couldn't remember it… :-P (suspicious)
WarGloom 04:12 :))))
taxilian 04:12 I was an interpreter for a church meeting
WarGloom 04:12 ого
try {
thread = plugin.createThreadRunner();
thread.addMethod(function(){alert("from THREAD");});
after click ok on aler box FBTestPlugin crashed
taxilian 04:12 yeah, I'm not sure that doing an alert while waiting for a signal is a good idea; that might just not work
doing it synchronously, I mean
try it with something that doesn't block like alert does
WarGloom 04:12 console.log?
taxilian 04:12 should be fine
WarGloom 04:12 aaa it is worked, i forgot that thread runner want string from calback
taxilian 04:12 hmm. could you send me a stack trace from the alert anyway?
I would still like to find a way to fix that
not sure if there is one or not
WarGloom 04:12 exception on convert_cast
taxilian 04:12 I have hte same problem with catching callbacks in a js debugger
oh, really? hmm. that's probably fixable
WarGloom 04:12 hm wait
о каком случае мы говорим ? :) о моем плагине или FBTestPlugin?
taxilian 04:12 either; just a crash that is occurring when you do an alert
working on a fix for your other issue, btw
WarGloom 04:12 form issue 123
taxilian 04:12 hmm. okay
might be able to fix that
should be able to
I'm probably doing something bad
WarGloom 04:12 :) мой плагин определенно падает на count
taxilian 04:12 yeah; that one is a browser bug
but I can work around it
WarGloom 04:12 do you need backtrace for this crash?
taxilian 04:12 you gave me one already, I believe
WarGloom 04:12 ye
taxilian 04:12
WarGloom 04:12 да, это он самый for chromium
taxilian 04:12 yeah, that's a browser bug (IMO)
WarGloom 04:12 a вот firefox перестал работать...
taxilian 04:12 or at least a serious oddity in how the NPAPI is working
but I'll work around it
WarGloom 04:12 он грузит плагин, но на каком-то месте теряет его, я еще не нашел где
может быть это связано с count,
taxilian 05:12 well, the real problem is that an exception is being thrown
and it isn't being caught correctly by the browser
which freaks out
and crashes in a burning fireball of DEATH
more or less, anyway
WarGloom 05:12 :-D
taxilian 05:12 checking to see if this builds
if it does, I'll push it to my private fork for you to test
WarGloom 05:12 nothing change
taxilian 05:12 I'm still trying to compile
WarGloom 05:12 compilation successful but chromium crash and firefox loosing my plugin
taxilian 05:12 I haven't pushed yet
I'm still trying to compile to make sure my fix at least builds =]
WarGloom 05:12 fuf, but i found 2 place in my plugin where methods returned int instead long...
taxilian 05:12 that's actually "okay" now; it'll throw an exception, however, if the values are out of bounds
WarGloom: git pull tax master again
WarGloom 05:12 compiling
FB_GitHubBot 06:12 FireBreath: master Richard Bateman * 70c842b (7 files in 2 dirs): Fixed some compiler warnings, experimental fix for using an NPObject that has been passed back into the plugin that started out as a JSAPI object from the plugin
FireBreath: master Richard Bateman * ae320d1 (1 files in 1 dirs): Fixed bug / crash caused by no appender selected with log4cplus
FireBreath: master commits 1c93351...ae320d1 -
FB_GitHubBot 06:12 FireBreath: master Richard Bateman * 464f46c (1 files in 1 dirs): Fixed typo -
FireBreath: master Richard Bateman * efc7121 (1 files in 1 dirs): Fixed missing header file -
taxilian 06:12 this is what I get for coding at 7am...
taxilian 07:12 does anyone have any thoughts on the idea of changing the default constructors for FB::variant so that to give it a type that it is not familiar with you have to pass an additional parameter? (basically so that it won't implicitly allow you to just assign anything; you still can, but it needs to be a type that the browser can handle or you have to pass in (type, true) or some such
FB_GitHubBot 08:12 FireBreath: master Kevin Menard * be86a14 (4 files in 1 dirs): Added some DOM conveniences. -
taxilian 08:12 nirvdrum: cool =]
nirvdrum 08:12 I finally cut over from hg to git.
This is going to make my life so much simpler :-)
taxilian 08:12 hehe
yep =]
nirvdrum 08:12 Even managing my own branch or fork is going to be a lot easier.
But landing on master is even better ;-)
taxilian 08:12 =] there are some pretty major improvements in master right now
that does mean that they need some pretty major testing
please let me know if you find any issues
nirvdrum 08:12 I've been trying to stay on top of the email list & IRC messages. Alas, working on our plugin isn't a fulltime endeavor for me, so I only get to play with the new firebreath stuff every month or so.
taxilian 08:12 hehe. yeah, I understand how that goes
nirvdrum 08:12 Man, it's so nice not having to track different hg repos anymore.
taxilian 08:12 lol
jtojanen 09:12 Seems like the setAPI change has broken IE when no params are passed in.. have you seen this?
taxilian 09:12 I haven't; what are the symptoms?
jtojanen 09:12 Plugin won't work as m_api is null
If <object> has no <param> IE won't call the STDMETHOD(Load)(IPropertyBag *pPropBag, IErrorLog *pErrorLog)
taxilian 09:12 hhmm.. I bet that means that IE is not even calling Load if there is nothing there
that's lame
jtojanen 09:12 true
taxilian 09:12 thanks for letting me know...
now we just have to figure out how to fix it =]
jtojanen 09:12 SetClientSite is the right place
The only place
taxilian 09:12 setAPI ideally should not be called until after Load has been called
however, sometimes Load is called after setAPI
most frustratingish
sorry, Load is sometimes (always?) called after SetClientSite
jtojanen 09:12 Load is called if <object> has at least one <param>
taxilian 09:12 right; that makes sense, now that I think about it. I was thinking it gets called always
jtojanen 09:12 Noup
taxilian 09:12 so the problem is that the API should not be created until after Load is called, iff it will be called
but Load is at least sometimes called after SetClientSite
very frustrating
jtojanen 09:12 I will check if there is any workaround
taxilian 09:12 ok; obviously, we will move it back to SetClientSite if we can't find a better way
jtojanen 09:12 For now
taxilian 09:12 but that will be kinda annoying, since there is then no hook to say "we're completely initialized and you have your params"
jtojanen 09:12 Or add a dummy param
It may be that in-place activation happens after this....
taxilian 09:12 you sound like you actually know your way around ActiveX
that's really rare around here
as soon as I get my PC booted up I'll dig through my COM books and see if I can find anywhere where the lifecycle is documented
jtojanen 09:12 Playing around with those for a decade
taxilian 09:12 doubtful, but who knows?
really? please stick around :-P I may need your help =]
I've only used COM to do browser plugins
jtojanen 09:12 We are still using COM servers
taxilian 09:12 cool. trying to think; have I talked with you before?
not recognizing your nick offhand
jtojanen 09:12 I will get back to you later
no we haven't
taxilian 09:12 cool. well, welcome; I really could use some suggestions on a few things if you have time sometime. =]
taxilian 09:12 ahh, I think I have a solution
Jamil 09:12 hi nitrogenycs
nitrogenycs 09:12 hi Jamil
Jamil 09:12 I had discussion with Taxilian about sending base64 data to the server
I found that BrowserStream is written by you
nitrogenycs 09:12 yes
Jamil 09:12 can you tell me how you see the simplest and fast way to send this base64 for both IE and Firefox?
nitrogenycs 09:12 it depends on a number of factors
first, do you need to support proxies completely transparent
second, how big is your data
third, are you in control of the server side or do you have to use existing apis?
the answer for simple and fast will depend on these factors
Jamil 09:12 second: 3K of base64
third, yes I have control on the server
nitrogenycs 09:12 Jamil: Why not use ajax request for 3k data?
Jamil 09:12 how
nitrogenycs 09:12
Jamil 09:12 any sample or guide
nitrogenycs 09:12 there are many many guides for xhr request, search for xmlhttprequest or xhr or something like that
Jamil 09:12 can I use it from firebreath
nitrogenycs 09:12 you can use it from javascript, so you can use it from firebreath
taxilian 09:12 actually, you probably could; I've never actually tried. t hat would be interesting. Worst case you could eval something to create the object, etc
we really need to just add POST support to browserstreams
nitrogenycs 09:12 it's not that easy imo
everything has drawbacks
Jamil 09:12 yes taxilian told me that
taxilian 09:12 adding POST support?
nitrogenycs 09:12 yes
there is no "good" way
well maybe "perfect" :-)(
taxilian 09:12 even if you just want to do a simple text-only post?
granted, it won't allow uploads or binary data, but text should be fine
nitrogenycs 09:12 no, but then you assume your upload size is small I gues
the POST npapi stuff does not stream things
it seems you have to provide one gargantua memory buffer
so if you want to upload a 3gb media files that gets hairy on 32-bit systems :)
taxilian 09:12 well, you can also provide a file
but it has to be a text file =]
Jamil 09:12 I know my data is not more than 3K of base64
taxilian 09:12 I don't think we need to worry about huge files
nitrogenycs 09:12 Jamil: use xhr, I think that's what everybody using javascript uses
jQuery etc has builtin support for it
I for one, need huge files
taxilian 09:12 nitrogenycs: well, for huge files it's not a good solution
use the HttpClient class (which we need to clean up a bit) for that; it uses openssl and libcurl and works well
Jamil 09:12 ok, good idea to my firebreath function will return the base64 then I will send it to the server using xhr
taxilian 09:12 though it's hard to say how well the proxy detection will work
worth trying
the disadvantage to using xhr is that you are probably limited to the page's cross domain policy
nitrogenycs 09:12 Jamil: yes, or you do the base64 encoding in javascript if that's easier for you. Both ways work
Jamil 09:12 let me try this and I will let you know
taxilian: why host->createStream is not working when I run from my plugin
nitrogenycs 09:12 cross domain request: there are methods to circumvent that, but obviously some are better, some are worse
taxilian 09:12 Jamil: given that information, I have absolutely no idea
you've gotta be a little more specific
"not working" is about as helpful as mentioning that I live in the northern hemisphere
nitrogenycs 09:12 taxilian: All the methods which do not use the browsers function for sending the data can hit proxy problems since there should be no way to discover the proxy's password
Jamil 10:12 I wanted to run the StreamsTest from the SimpleStreams
taxilian: ok I see why
we have proxy password here in company
is xhr has this proxy problem?
taxilian 10:12 xhr would not, no
nitrogenycs: agreed; that is why I would prefer to find a way to have basic POST support in BrowserStreams, though I realize it will be limited
Jamil 10:12 let me try xhr...I need to go now
thank you all
taxilian 10:12 good luck
nitrogenycs 10:12 taxilian: yes, I see. I've still no decided on the method I am going to use for uploading files, so I am currently hesitant to start the implementation. I've got lots of server side coding to do at the moment.
taxilian: I think I don't want to wrestle with the proxy stuff and I also want to be able to upload bigger files.
taxilian 10:12 nitrogenycs: I'm currently using the HttpClient class w/ libcurl for uploading and it works great — with progress reports. I think that's as good as we can do despite the proxy drawbacks for full upload support
it can upload big files and even batches of files (in multiple batches)
nitrogenycs 10:12 taxilian: These goals kinda exclude each other at the moment. Maybe POST encoded base64 files are the solution, but I've yet to see
taxilian 10:12 I don't think they are related, to be honest
different problems
the HttpClient class actually works pretty well for file upload, though
nitrogenycs 10:12 taxilian: they are not related on the semantic level. They just exclude each other if you look at the table of possible solutions. XHR is proxy ok, big files bad. POST streams is big files bad, proxy ok. Curl is proxy bad, big files nice.
I can get progress reports from my server even with POST streams
so I might have to bite the bullet and write base64 encoded temporary files and then submit these
taxilian 10:12 makes sense. the added overhead of the base64 (increased filesize) would kill us
but I just have to be "better than flash", so the proxy issues are workable
nitrogenycs 10:12 yeah, I can see how your solution also makes sense
if everything else fails I'll have to chunk the big files, but I'd rather like to avoid that
the browser vendors should update their lousy upload implementations
there's html5, fancy video, 3d canvases but no decent upload support....
to be fair, it's only the NPAPI browsers
taxilian 10:12 hehe
taxilian 10:12 that was weird...
FB_GitHubBot 10:12 FireBreath: master Richard Bateman * 96dd39d (1 files in 1 dirs): Fixed bug caused by recent fix where IE plugins don't work correctly without params -
taxilian 14:12 is anyone in here using visual studio 2005?
nitrogenycs 14:12 not anymore
we've dropped it years ago
taxilian 14:12 hmm. I may have to install it somewhere again just to test :-P
I just about have it working so you can use visual studio express + winDDK without making any changes to your visual studio config
they both just have to be installed
FB_GitHubBot 14:12 FireBreath: master Richard Bateman * f1cc25d (10 files in 8 dirs): Added full support for Visual C++ Express edition 2008 and later with windows DDK installed but no changes to visual studio config if ddk is installed in default location
FireBreath: master Richard Bateman * 48f49dc (2 files in 1 dirs): Tweaked inclusion of atlthunk.lib so that it will only link against it if it is found in the chosen lib dir
FireBreath: master commits 96dd39d...48f49dc -
taxilian 14:12 well that seems to be working
so anyone using vs express it should be a lot easier now
no need to even add the include dirs, etc
cmake will find it all
nirvdrum 17:12 IS there a good way to tell which browser you're running in?
I've yet to figure out a common way to access the tab HWND and so I need to search by window class name, which is different for each browser.
taxilian 17:12 lol
the "best" way I know of is to parse the useragent
nirvdrum 17:12 That'd be good enough.
taxilian 17:12 at least if you're on npapi, of course
nirvdrum 17:12 Does firebreath have a super easy way for me to get that?
taxilian 17:12 but you can tell if you're on IE pretty easily
nirvdrum 17:12 Yeah, this is NPAPI only.
taxilian 17:12 well, I don't normally reocmmend this
but you're kinda a special case
since it's not a plugin you're distributing
nirvdrum 17:12 I have IE handled pretty nicely.
Heh, yeah.
taxilian 17:12 just FB::ptr_cast<FB::Npapi::NpapiBrowserHost>(m_host)
nirvdrum 17:12 Right now I'm Chrome only. I'm looking to make it work with Safari.
taxilian 17:12 and then you can call ->useragent()
nirvdrum 17:12 It may turn out that they both use the grandparent of the plugin window, but it seems even more hackish to rely on that.
taxilian 17:12 good luck
nirvdrum 17:12 Indeed.
taxilian 17:12 for my next trick, I'm going to try to integrate a crash handler into a firebreath plugin
nirvdrum 17:12 I'm just happy right now that for the first time, I did a big pull in of Firebreath and my plugin still compiled.
And even works.
taxilian 17:12 lol
I won't tell you about the semi-breaking change I introduced today, then :-P
(actually, it only affects plugins that want to compile in vs express)
nirvdrum 17:12 Ahh, that won't affect me then :-)
taxilian 17:12 likely not =]
well, sounds like I gotta get going
good luck
nirvdrum 17:12 See ya.
nirvdrum 17:12 taxilian: Any idea why NpapiBrowserHost has an isSafari method?
taxilian 20:12 It should work
I wrote it
nirvdrum: There was a time before we finally found the cause of a really weirs issue that we had to do strange workarounds in Safari