|IRC Nick||Time (GMT-7)||Message|
|dgirsh||03:08||guys, "prep2012.cmd examples" doesn't woks. See http://pastie.org/8229009
Sorry for the grammar errors.
|zokier`||03:08||is qt a good choice for making a simple ui in a plugin?|
|ceterumnet||15:08||taxilian: I haven't been able to get back on my customer's system to do any more troubleshooting with my DLL crash issue - but I was thinking about the difference between a debug and release build on firebreath. Is there any area in the code that you can think of in Firebreath that has subtle timing differences or anything else that might only reveal itself on a small percentage of systems?
perhaps something that can change the order of certain calls in the plugin lifecycle?
|taxilian||15:08||zokier`: qt is a royal pain in the neck to use in anything that isn't already designed to work with qt
ceterumnet: there is no promise of when in the lifecycle the AttachedEvent gets fired
so if you're doing some things there and some in pluginLoaded it could be getting called in a different order
|ceterumnet||15:08||taxilian: ok - what about thread safety in general for a given instance of the plugin? Would any of the JSAPIAuto methods be invoked before onPluginReady?|
|taxilian||15:08||it's not a question of thread safety
the browser only calls the plugin on one thread
that's my question
|taxilian||15:08||it is possible that a jsapiauto method could be invoked early, though|
|ceterumnet||15:08||sorry for the poor wording
but on the same thread
so if you are polling it or something before that is fired it could possibly get in before onPluginReady
that's why I use the "onload" param and don't access it before that's fired
|taxilian||15:08||could be it|