IRC Log Viewer » #firebreath » 2011-02-23

IRC Nick Time (GMT-7) Message
mital 00:02 taxilian: hey
taxilian 00:02 howdy
mital 00:02 I am good
how are you doing .??
taxilian 00:02 busy
really busy
mital 00:02 I have been busy working on my project related stuffs...
yeah I can understand...
FB_GitHubBot 01:02 FireBreath: master Richard Bateman * 1bb2d6d (1 files in 1 dirs): Added experimental incomplete mac installer support to FBTestPlugin - http://bit.ly/gty02i
solan5891 07:02 greetings all, anyone here who can help nudge me in the right direction of what needs to be done to be able to draw (anything) on the screen under linux? i've checked out the FBTestPlugin sample project, but that only implements drawing code that runs under windows only :(
JohnD 07:02 has anyone ever made a SWFObject style utility for their plugin to ease installation/detection?
jshanab_wcw 08:02 I am trying to use jquery to bind to the javascript event created by my plugin.. i have examples of jquery working and of Firebreath but has anyone gotten them to work together
solan5891. I have been working with SFML so that I can easily port to mac and linux in the future. I cannot say if it will work, but if you try it and it does i will be very interested in swapping stories
solan5891 08:02 thanks for the tip jshanab_wcw
neilg_ 08:02 JohnD: No idea what you mean by SWFObject style utility but I can detect whether my plugin is installed and/or its version
(via Javascript)
I'm guessing that's what you're asking - but its an assumption!
*it's
Wireless keyboard is dying :(
solan5891 08:02 i checked it out (sfml), but it may be a bit of an overkill for my project - all i want is to get console output and a simple opengl drawing to appear in the window, using firebreath under linux
JohnD 08:02 neilg_, yes that's what I mean. If you google SWFObject it's a little JS library which is cross-browser and will automatically show an install link etc
neilg_ 08:02 Then the answer is yes - I have this. :)
JohnD 08:02 do you know if FB has an example of this? Or maybe you might let me take a look or even donate an example to FB for everyone? No offence if the answer is no :)
jshanab_wcw 08:02 It is suppose to be "Small Fast.." :-) it didn't add to much to my plugin all dlls combined less than 2Meg
neilg_ 08:02 It's very simple to do as well, I have a property in my plugin which contains the version of the plugin. In Javascript I check for that property inside a try...catch block. If I catch an exception then the plugin isn't installed. If either that happens or the version is lower than I need then I update the div with a link to the latest version of the plugin
I've pasted code to the mailing list before, perhaps it's something I should add to the wiki...
JohnD 08:02 I'm sure I'm not the only one who would benefit :)
taxilian 08:02 solan5891 FBTestPlugin doesn't draw at all
solan5891 08:02 oh
taxilian 08:02 To draw in Linux you need to look at PluginWindowX11
raffaello 08:02 Hi
taxilian 08:02 You get it from AttachedEvent
neilg_ 08:02 JohnD: I have no problem doing that
solan5891 08:02 oh, i thought "FBTestPlugin::draw( FB::RefreshEvent *evt, FB::PluginWindow* win )" was doing some magic
raffaello 08:02 i have a question..How can i add string to the default resource file (firebreathWin.rc)created by firebreath?
taxilian 08:02 rafaello: copy firebreathWin.rc to your plugin directory
then modify it
raffaello 08:02 thanx!!
taxilian 08:02 solan5891: oh, I guess that is doing a little bit
raffaello 08:02 :)
taxilian 08:02 forgot about that
that's newish
solan5891: you need to do kinda the same thing, but you need to get a PluginWindowX11
you can get it the first time from AttachedEvent
it goes away with DetachedEvent
you can find the source in src/PluginAuto/X11/
to see what methods there are
I think for some reason it's not showing up on the doxygen docs yet; haven't had time to track that donw
solan5891 08:02 taxilian: thank you, by the way is this a relatively new class? i haven't yet come across it on the wiki
taxilian 08:02 solan5891: no, it's old as anything
just not many people draw on X11 and nobody has added it
I don't have time to do all the docs myself
feel free to add it yourself
JohnD: there are two pieces to do what you want in the FireBreath codebase
for detection, the script in Installer/js/fb_installer.js is pretty easy to customize for detection
and at least mostly works
and for inserting you could copy the code from examples/FBTestPlugin/test.html
also pretty easy
some others use different detection methods where they always insert it into the DOM, but I dislike that method because it has more side-effects than the method used in the fb_installer.js
actually, we really should add an insertion script to fb_installer.js
feel free to submit a patch if you'd like ;-)
jshanab_wcw 08:02 Good morning taxilian. By any chance, Have you ever gotten events to work with JQuery. I bind but it seems to ignore the events fired. I trace the plugin and the FireEvent is called and regular javascript works well.
taxilian 08:02 jshanab_wcw: I spent many hours trying really hard one day and finally came to the conclusion that it can't be done
the reason is that jquery tries to call functions wtih .apply(plugin, arguments) and aparently the plugin can't deal with being the context object
the other reason is that jquery expects Event objects to come as the parameter. I even added a new type of event to FireBreath (FireJSEvent) to try to provide the right object, and I got a bit further
but it still freaks out
jshanab_wcw 08:02 taxilian. oh...S**t
taxilian 08:02 yeah, frustrates me too
I don't know if the jquery guys would consider adding any extra logic in there to help us or not
doesn't seem like the sort of thing that can easily be solved with a plugin
jshanab_wcw 08:02 Maybe I can wrap the events i want in some javascript
JohnD 08:02 @taxilian: "examples/FBTestPlugin/test.html" is that the one which just uses document.write? It didn't work properly for me
taxilian 08:02 JohnD: no, it uses innerHTML
and it works just fine on all browsers I've tested it on
which is pretty much all browsers on all three platforms
jshanab_wcw 08:02 I wonder how HTML5 does it, I have an example of jquery player that responds tot he events from the player
JohnD 08:02 ah yes, it definitely broke for me on IE8, or it sort of worked but the plugin didn't become visible
taxilian 08:02 JohnD: did you try installing FBTestPlugin and using test.html?
jshanab_wcw: if it was an html5 video player then it does it because it's a real DOM element
and not a plugin
solan5891 08:02 taxilian: thanks for the hand, i'll get back home from work now and try to make this work :)
taxilian 08:02 JohnD: it definitely, beyond any doubt, works fine in: IE6, IE7, IE8, (haven't tried IE9), Firefox 3.5, Firefox 3.6 (haven't tried 4), Safari, Chrome, and Opera on windows. Safari, Chrome, Firefox 3.5, Firefox 3.6 on Mac. Chromium and Firefox 3.5, 3.6 on linux
solan5891: good luck
solan5891 08:02 thanks, c you guys !
JohnD 08:02 not for me, I copy-pasted it. I definitely see something happen but my plugin is just rendering a big ugly black rectangle. I'm guessing I am making an assumption on how things are happening in my own code, didn't have time to look deeper yet.
taxilian 08:02 does that differ from when you just put the object tag in?
JohnD 08:02 yes
taxilian 08:02 did you look in the DOM to see what was actually inserted?
JohnD 08:02 not yet, I'd have to learn how to us the IE tools and didn't find time. I saw it didn't work so rolled back to just having <object>
I will when I work on it next
is it possible to try and detect the plugin without instantiating it?
or i that the only way, try and see if it works?
taxilian 08:02 yes; look at Installers/js/fb_installer.js
well, on IE you have to instantiate it
but you can instantiate it without a window, from javascript
make sure you're on 1.4 for that
JohnD: use Jash to examine the DOM if you're not familiar with IE tools; it's pretty easy to set it to dump the html of whatever you mouse over
also, that script expects you to put the plugin in a div and use the div for sizing
JohnD 08:02 that's fine with me
taxilian 08:02 I would strongly recommend that you brush up on your javascript and html if you're working on plugins, though :-/ if you don't have a good solid understanding of working in the dom then working on plugins is a pain
however, I promise that that script works; it's not generic, but it shouldn't be hard to make it so.
JohnD 08:02 did you say if any of the tests _use_ this, to see it in action? test.html uses it?
taxilian 08:02 yes
JohnD 08:02 ok, cool
taxilian 08:02 if you build the examples and install FBTestPlugin you can load test.html and it works fine
JohnD 09:02 I'm not a web-dev really but I can struggle by if I have to
taxilian 09:02 wait; uses the insertion, not the detection
unfortunately, to do plugins well you really need to be both :-/
but you can learn =]
JohnD 09:02 my plugin use doesn't really require interaction with the page other than the bare minimum but nevermind :) So does anything demo the detection?
raffaello 09:02 taxilian: i copied the resource file in my project folder and i run the prep command but the resource files han not been added to the solution..
do i have to modify one of the cmake files?
JohnD 09:02 hmm in the top part of the fb_installer.js, is that using CMAKE vars or am I supposed to replace those ${xxx} vars?
e.g. "name" : "${FBSTRING_PluginName}",
taxilian 09:02 you could do it either way
if you put it in a templates/ directory under your plugin it will automatically configure it for you and replace those variables
and put it in <build>/projects/<plugin>/templates/fb_installer.js
JohnD 09:02 that's pretty neat. Is that covered in the wiki anywhere?
taxilian 09:02 no
probably should be, though =]
JohnD 09:02 do you mean a /tempaltes dir asa sibling to the Mac, Win & X11 dirs in fb/projects/MyPlugin
taxilian 09:02 yes
to be honest, I'd forgotten that I put it in there myself until I stumbled on it the other day
JohnD 09:02 :)
taxilian 09:02 feel free to add it. maybe to tips and tricks?
another good way to find things is to search the logs, btw: http://logs.firebreath.org
JohnD 09:02 I'm paused on my plugin right now seeking internal funding, if I get it I will look at this and will try to remember to put it in the wiki if nobody beats me to it
FB certainly made gettinga working plugin possible
without it I think we'd never have got started
raffaello 09:02 taxilian: i copied the resource file in my project folder and i run the prep command but the resource files han not been added to the solution..
taxilian 09:02 raffaello: it won't show up as a new file
firebreath will use it instead of the old one
you should then change it and run cmake before building
cmake will configure it
raffaello 09:02 and will it be placed under generated directory?
taxilian 09:02 yes
under gen/ instead of templates/ but otherwise in the same place as what I was telling JohnD
raffaello 09:02 mmm..i'm making some mistakes..cause if i change the resource file i created nothing happens
taxilian 09:02 did you rename the file?
raffaello 09:02 i tried both to rename the file and to leave the default name
taxilian 09:02 it must be the same name
raffaello 09:02 i put it under firebreath/projects/<plugin>/Win
taxilian 09:02 can't be in Win
has to be in the root of the project
raffaello 09:02 ok..trying
nope..do i have to copy also the global folder?
taxilian 09:02 global?
should be in firebreath/project/<plugin>/
you have to re-run the prep script
raffaello 09:02 yes..i did that
taxilian 09:02 what version are you on?
raffaello 09:02 i'm using the version from the repo
and i have updated it i thnk about 5 days ago
and i have updated it i think about 5 days ago
taxilian 09:02 master? firebreath-1.4?
raffaello 09:02 git clone git://github.com/firebreath/FireBreath.git firebreath-dev
taxilian 09:02 master, then
hmm. I will have to look. maybe that feature is broken in 1.5
raffaello 09:02 thanx
by the way...nice job!!firebreath is realy nice!
taxilian 09:02 thanks, I enjoy it =]
raffaello 09:02 i see now that when i run the prep command two files has been generated..
taxilian 09:02 raffaello: could you try it with specifying the projects and build directories manually and adding "-DVERBOSE=1" at the end?
ahh, I see the problem
update, it should be fixed
FB_GitHubBot 09:02 FireBreath: master Richard Bateman * e549525 (2 files in 1 dirs): Fixed error in project file generation from cmake refactor - http://bit.ly/dOVvPO
taxilian 09:02 gotta run now; need to go to the dr, see if I have strep throat
raffaello 09:02 thanx a lot!
taxilian 09:02 bbl
raffaello 09:02 taxilian: now if i change the value of the String i have in the rc file it change it also in the solution..
but if i add a new string in the rc the solution won't load the resource..
i think because the resource,h file is not updated with the new string
raffaello 10:02 i have to go..thanx for your help taxilian
bye
taxilian 10:02 anyone here used PackageMaker?
FB_GitHubBot 10:02 FireBreath: firebreath-1.4 Richard Bateman * 0401f33 (3 files in 1 dirs): Fixed issue #149 - crash when safari calls globalinit a second time - http://bit.ly/huLGJz
FireBreath: master Richard Bateman * 558d78e (2 files in 1 dirs): Fixed issue #149 - crash when safari calls globalinit a second time - http://bit.ly/fXNDpq
amackera 11:02 taxilian: I don't use PM, I distribute with disk images
taxilian 11:02 amackera! long time no see!
how you doing?
I'm putting together a little helper macro for generating mac installers
planning to support dmg and pkg, maybe tgz as well
FB_GitHubBot 11:02 FireBreath: firebreath-1.4 Richard Bateman * 97a6520 (2 files in 1 dirs): Fix for issue #150 - invalidatewindow incorrectly implemented - http://bit.ly/iertHe
jshanab_wcw 11:02 taxilian. http://pastebin.com/YDF76GVF
Here is how i worked around the issue. my jquery plugin now recieves events from the FB plugin, and it is per instance/object
What differs here is that our object with the mime-type is inside the named div, so we have to use the ...[0].children[0].addEventListener syntax
taxilian 12:02 I'll be back in a bit, my son is being a pill
taxilian 12:02 okay, back
yeah, that's more or less what I have done in the past
taxilian 15:02 awesome. netsplit. :-/
dan2 15:02 is there a default target for a plugin that is being built by cmake?
I need to add some linkage
circular dependency between a static and shared library (plugin)
taxilian 16:02 dan2: what do you mean by "default target"?
dan2 16:02 well I need the Plugin to link against a static lib
and I need the static lib to "hypothetically" link against the plugin
so I need a target for target_link_libraries
taxilian 16:02 http://www.firebreath.org/display/documentation/Using+Libraries
dan2 16:02 that does not answer the question
I need to link against the plugin
not against other libraries
well I do need that too
so the targetname is the PROJECT_NAME?
taxilian 16:02 yes
which is PLUGIN_NAME, unless you changed it
dan2 16:02 did not
physicsrob 18:02 Hello All -- I'm upgrading to firebreath 1.4 and I'm experience a crash on windows. It appears to be happing in FBControl.h line 334 (pluginMain->SetWindow(pluginWin)), but pluginMain is NULL. Anyone see this before or have any idea what circumstances could lead to this condition?
taxilian 19:02 hey physicsrob. what OS?
sorry, what browser?
wait, nevermind, that's answered too
hmm
the only way that should be possible is if a shutdown signal was seen or you didn't return a valid instance of your plugin class from the factory
physicsrob 19:02 The factory just returns boost::make_shared<MyPlugin>();
taxilian 19:02 look for where pluginMain.reset() is called, set a breakpoint there, and see if it gets hit
and when
physicsrob 19:02 ok
thanks
taxilian 19:02 you ever going to submit that patch for 10.4 support? =]
physicsrob 19:02 I actually did, a long time ago, but I don't think I properly communicated it with you. I have it in my local repository..
taxilian 19:02 I never got it
aparently
would it be hard to submit a pull request?
physicsrob 19:02 I'm not sure exactly how I would go about that.
taxilian 19:02 do you use git?
physicsrob 19:02 yeah
taxilian 19:02 if you just put it in your fork I can pull it over easily
ideally on the 1.5 branch
which, btw, has a complete refactor of the mac plugin windows
which I think you'll like
physicsrob 19:02 what do you mean put it in your fork?
taxilian 19:02 on github
if you fork FireBreath you can push changes to your fork
and I can easily see those changes and pull them across into the main repo
physicsrob 19:02 so that would involve creating a github account, forking firebreath, changing my remote repository, and pushing, correct?
taxilian 19:02 right
=]
physicsrob 19:02 sure
taxilian 19:02 how are things going, btw? haven't seen you around in awhile
physicsrob 19:02 fine -- just absolutely slammed. I'm very understaffed and can't find any qualified people to hire. At least at a salary I can afford to pay.
taxilian 19:02 that's always a pain
physicsrob 19:02 yep
one sec
hmm.. it's not letting me push
Robs-MacBook-2:FireBreath rob$ git pull
Already up-to-date.
Robs-MacBook-2:FireBreath rob$ git push
To [email protected]:physicsrob/FireBreath.git
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to '[email protected]:physicsrob/FireBreath.git'
taxilian 19:02 that's because you forked the current version
and what you have locally is not the current version
without any merging I suspect there are some major conflicts with the new pluginwindowmac classes :-/
physicsrob 19:02 sorry.. look's like it'll have to happen later
taxilian 19:02 you can force it to let you push, but that would override the changes in origin
how about this
do git push origin master:mac104
that will push your current branch to a new branch on the server
physicsrob 19:02 that worked
I just did a git push -f
git://github.com/physicsrob/FireBreath.git
taxilian 19:02 yeah, looking at it now
when you upgrade you'll have to rebase that branch
just FYI
physicsrob 19:02 If you merge these changes I wont have anything local -- so I'll just scrap it :)
taxilian 20:02 the only change I'm seeing is the KeyCodesCarbon.h file that relate to 10.4....
physicsrob 20:02 that's 99% of it
then theres an #ifdef in PluginWindowMacCocoaCA.h I believe
let me check
taxilian 20:02 ahh
is that all?
physicsrob 20:02 yep
taxilian 20:02 that should be easy enough to merge
it will go into 1.5, though, not 1.4
physicsrob 20:02 not a problem
cool :)
taxilian 20:02 when you get a chance, I really think you'll like the improvements to the pluginwindowmac classes
physicsrob 20:02 cool.. I'm sure
I'm hoping that you can do core graphics drawing in cocoa and carbon using the same code
taxilian 20:02 yep
physicsrob 20:02 that's great
taxilian 20:02 event model are seperate classes
there is one PluginWindowMacCG class
physicsrob 20:02 that probably makes more sense
taxilian 20:02 yeah
physicsrob 20:02 I thought a lot about the way I would refactor that... but I have a very java-centric mindset when it comes to OOP
and multiple-inheritance just isn't a replacement for interfaces
IMO
taxilian 20:02 no, it isn't
but we really didn't need either in this case
grr. gcc is obnoxious sometimes. my template isn't working and there are no hints as to why
physicsrob: anything new on that IE issue you were having?
physicsrob 20:02 BTW I am getting shutdown before InPlaceActivate
I feel like I had a very similar issue in 1.3 that you fixed, but I don't remember the exact details
taxilian 20:02 what is the call stack?
physicsrob 20:02 I'm sure this is related to my plugin-detection script. I do try { new ActiveXObject() } catch {} to detect if the plugin is installed before I create the actual plugin
the call stack for shutdown() ?
taxilian 20:02 yes
how new is your plugin?
sorry, firebreath
how recently have you updated?
'cause I think that's a bug I fixed a few days ago
physicsrob 20:02 hmm
one sec
let me recompile
FB_GitHubBot 20:02 FireBreath: master Richard Bateman * 3ff5d95 (4 files in 3 dirs): Fixed bug with fix for issue #151 on mac/linux - http://bit.ly/h0axiM
physicsrob 20:02 hehe cool bot
taxilian 20:02 part of github
FB_GitHubBot 20:02 FireBreath: firebreath-1.4 Richard Bateman * db98a52 (2 files in 1 dirs): Fixed bug with fix for issue #151 on mac/linux - http://bit.ly/ecP3Ql
physicsrob 20:02 visual studio is so slow. argh.
taxilian 20:02 heh
you can build from the command line
just cmake --build <builddir>
physicsrob 20:02 really?!?!?!?!
how did I not know this
that's awesome
taxilian 20:02 where builddir is the build directory you put cmake files into
very handy for build servers
physicsrob 20:02 I actually do my windows development in a VM on my mac
but I do all the editing in xcode :)
taxilian 20:02 hehe
well, that might be handy, then
physicsrob 20:02 the more I can stay away from windows gui stuff the happier I am
taxilian 20:02 you could isntall openssh server under cygwin on the VM and do everything over ssh
physicsrob 20:02 will it do a partial build, or always from scratch?
taxilian 20:02 parial build, but there is a bug of sorts in the cmake config right now that makes that partial build less partial than it should be
hwoever, if you're not changing firebreath stuff it should only have to rebuild PluginAuto and your plugin
physicsrob 20:02 that's not bad...
that makes me want to get a build server
just a cheap windows box would be better than the VM I'm sure
taxilian 20:02 yeah
definitely would be
you can also use CoRD for remote desktop to a windows machine
physicsrob 20:02 what's CoRD?
taxilian 20:02 it's a better rdesktop client for mac
for connecting to windows machines using the rdesktop protocol that is there by default
physicsrob 20:02 very cool
that's a good idea
taxilian 20:02 the advantage of being fluent in windows but doing most of my work on a mac =] I learn lots of random tricks :-P
someday I'll get better at Mac development
but there always seems to be someone around who knows mac development better than I and nobody who knows windows dev
physicsrob 20:02 that's surprising
you would think it would be the other way around
considering market share
but I guess developers like mac
taxilian 20:02 well, but if you consider that the first requirement for the jobs where it ends up mattering is that they know plugin development, it's less weird
the one I'm working with now is the guy who refactored the pluginwindow classes for mac
he's been doing mac development for 25 years or so
physicsrob 20:02 wow
still compiling.. this is ridiculous
taxilian 20:02 yeah; it takes about twice as long to compile on windows as other platforms
not sure why
physicsrob 20:02 MS... it's a catchall answer :)
physicsrob 20:02 okay... finally rebuilt with the latest
still have the problem
shutdown is getting called from InPlaceDeactivate
taxilian 20:02 hmm. can you tell if this is a detection (created with ActiveXObject) or an object tag?
physicsrob 20:02 one sec
very strange
this is the sequence: Plugin Constructor Called (this=5012cf4), Plugin Constructor Called (this=5063f6c), InPlaceActivate called (pluginMain=5063f6c), shutdown called (pluginMain=5063f6c), Plugin Destructor Called (this=5063f6c), InPlaceActivate called (pluginMain=NULL)
I assume the first plugin that's created is the ActiveXObject -- after all that happens earlier in the javascript
specifically I check to see if the plugin is installed with ActiveXObject, and then insert HTML for an object tag into the DOM
taxilian 21:02 try this: comment out shutdown() from deactivate and set a breakpoint on the shutdown that is in SetClientSite to make sure it is called
also in SetSite
SetSite should be called for ActiveXObject, SetClientSite for object tags
physicsrob 21:02 okay
taxilian 21:02 are you drawing?
physicsrob 21:02 no
not yet
I have my drawing code disabled at the moment
taxilian 21:02 okay, but you plan to
that was my question
physicsrob 21:02 yeah
I plan to
taxilian 21:02 I'm betting that will fix your problem
just need to make sure that the other shutdown gets called
that was put in as a workaround when we were having some issues with activex
I'll do some testing and put that fix in the 1.4 branch if you confirm it works
I need to put my son to bed; I'll be back later
prolly 30 min
physicsrob 21:02 okay. thanks
physicsrob 21:02 thanks Richard! That fixed it!
taxilian 21:02 is shutdown still being called correctly?
and the object destructed?
physicsrob 21:02 let me double check
taxilian 21:02 it isn't
that throws off our shutdonw
hmm. will have to think
bbl
physicsrob 21:02 yeah -- it's not
It seems like InPlaceDeactivate is being called for the wrong plugin
physicsrob 21:02 this is very strange. I'm getting the following sequence: InPlaceActivate(pluginMain=4f6faec, this=4f750a0), InPlaceDeactivate(pluginMain=4f6faec, this=4f751ac), InPlaceActivate(pluginMain=4f6faec, this=4f750a0)
so I have multiple ActiveX controls pointing to the same plugin object?!?
taxilian 21:02 wait… that shouldn't be possible
that's really weird
so when you put the plugin object in the DOM, are you doing anything weird to it? moving it around in the dom, setting css on it to make it hidden, etc?
physicsrob 21:02 uhm, not right now
taxilian 21:02 you just drop the object tag directly into the dom?
you're not creating an object tag, then appending it to something after?
setting it with innerHTML?
physicsrob 21:02 I'm creating a div, setting the innerHTML to an object tag, and appending it to some other element
taxilian 21:02 try appending it to the other element first
physicsrob 21:02 unfortunately that's not possible
taxilian 21:02 make it possible
if only for testing
to verify
physicsrob 21:02 hmm
taxilian 21:02 as a general rule, plugins don't like to be moved around in the dom; it does funny things to them
it's quite possible that moving it as you do (because yes, it does create the object when you set the innerhtml, then moves it when you put it in the dom) you're causing the inplacedeactivate
physicsrob 21:02 agreed, I've had experience with that, but the plugin shouldn't be generated until it's attached
I think
taxilian 21:02 I wish
physicsrob 21:02 hmm
really?
taxilian 21:02 my experience says otherwise
but it's been a long time; I could be misremembering
so check it to be sure
physicsrob 21:02 perhaps thats browser dependent
my experience most likely comes from safari
taxilian 21:02 I believe it does happen differently on different browsers, yes
physicsrob 22:02 anyway.. this wasn't a problem in 1.3
taxilian 22:02 sure wasn't
physicsrob 22:02 and the javascript is identical
taxilian 22:02 of course, 1.3 was leaking memory like crazy
but it didn't crash!
if you want to replicate that feature, simply remove the shutdown call from InPlaceDeactivate
in the mean time, I'm trying to find a better solution
physicsrob 22:02 okay... well at least that's one option
taxilian 22:02 but it would be helpful to know for sure that is what is happening
physicsrob 22:02 I'm going to place some more breakpoints and verify what I just saw. It really should not be possible
taxilian 22:02 I'll agree with you there.
why is it so hard to set the innerHTML after appending it to the dom?
particularly just to try?
physicsrob 22:02 in general because I bundle a javascript library with my plugin that has a method for getting the plugin object (so the user can append as needed).. really it's just a div that contains the plugin
taxilian 22:02 may I suggest an alternative pattern?
physicsrob 22:02 sure
taxilian 22:02 btw, I just confirmed that the object is created as soon as you put the innerhtml in the div
put the div in the page and have the user call a function that takes either the id of the div or the div itself
and injects the plugin into it
take a callback as the second parameter and set it up so that onload calls that function
see examples/FBTestPlugin/test.html for an example
physicsrob 22:02 that's not a bad idea, but it's not feasible for me
I have customers relying on the API
taxilian 22:02 well, I don't see another option, I'm afriad
you could leak memory,b ut you would be leaking a *lot* of memory
physicsrob 22:02 why do you say that it's a lot of memory?
taxilian 22:02 if the activex object doesn't shut down, nothing else does either
your plugin object, your api objects, etc
none of it will get released
physicsrob 22:02 my plugin object destructor is getting called, though
?
taxilian 22:02 are you sure?
physicsrob 22:02 I'll double check, but I'm pretty sure
taxilian 22:02 it's still not a good option
tell me what your API is; maybe I can help you find a way to salvage this
because I just tested it myself; moving a plugin around in the DOM is a BAD idea, and that's essentially what you're doing
at least on IE
physicsrob 22:02 i just confirmed -- my destructors are getting called
taxilian 22:02 are you sure that's not just from the ActiveXObject versions?
because shutdown() is never being called, right?
and that's what releases your plugin object
also what releases all browser resources that we're holding
physicsrob 22:02 ~CFBControl ends up tearing down the plugin
with shutdown commented out
shutdown is not getting called
taxilian 22:02 if shutdown is not called, ~CFBControl never gets called
if you're seeing it it's probably from the ActiveXObject
which is getting called correctly, as far as I know
physicsrob 22:02 no, the destructor is getting called twice
once for the activexobject detection, once when I browse away from the page
taxilian 22:02 then you have the weirdest IE configuration I've ever heard of
and I wouldn't count on that working on any other machine
physicsrob 22:02 CComObject::Release is the lowest point in the stack
it's just vanila XP SP3 with IE8... nothing strange going on here
taxilian 22:02 well, it's up to you… but I'm warning you that you will have problems if you try to keep it that way
physicsrob 22:02 I just want to understand what's going on before I force issues upon my customers... hmmm
taxilian 22:02 well, I can tell you this: when I reproduce those steps in jash (create div, inject object tag, then add div to document.body) I get a constructor as soon as I add the object tag and a deactivate when I add it to the dom
physicsrob 22:02 really
interesting
taxilian 22:02 yeah; no special javascript, nothing
just jash
there is probably a way to make firebreath handle that all correctly, but it won't be in 1.4
and we have to figure out what it is before it goes in anything
the problem is that we hold references to a lot of things in a lot of places
physicsrob 22:02 I'm not trying to imply it's your problem -- I understand it's mine
taxilian 22:02 I'm just laying out the issues
I'm not offended or anything — no worries
if those things aren't released on some platforms (on my win7 ie8 for example) the destructor is never called
and nothing gets cleaned up
physicsrob 22:02 so why wasn't this an issue in 1.3
my destructor was getting called in 1.3
taxilian 22:02 because we were doing things wrong in 1.3
so FBControl still never got destroyed
but when the window was destroyed we deleted pluginMain
physicsrob 22:02 gotcha
taxilian 22:02 hard to do when you support windowless, for one
and for two, it still leaked memory
physicsrob 22:02 hmm
that's an interesting thought
I'm planning on switching to windowless
same issues?
taxilian 22:02 yep
so here is an idea
we could create a data structure that could live in a shared_ptr that could be used anywhere that we currently pass around references to the COM objects
that way they are in one place where we can find them
we can release them on deactivate and if needed we could fetch them again on activate
that way it could shut down the plugin or start it back up again
might be doable
physicsrob 22:02 hmm
taxilian 22:02 hmm. of course, we'd have to release all IDispatch objects that we have gotten from javascript as well
physicsrob 22:02 well that's definitely over my head
taxilian 22:02 it isn't a simple problem
so you could use a setTimeout to wait until the div in question has a parentNode
and then inject the object tag
physicsrob 22:02 haha
that's a really clever solution
taxilian 22:02 really hacky, but doesn't mess up your API
physicsrob 22:02 I like it
taxilian 22:02 trust me, I have lots of experience (mostly that I try to forget) of coming up with weird javascript workarounds. *shudder*
physicsrob 22:02 I could just poll the element to see if it has a parent
taxilian 22:02 right
as long as it's within, say, half of a second, they probably won't even notice
and if you think that's too long, make it 1/4 second
physicsrob 22:02 I do have a piece of my webapp that deliberately moves the plugin
and it's been really buggy
so I'll probably have to redesign that anyway
taxilian 22:02 yeah, I would really avoid doing that
if you need to move it physically, put it in a floating div
and position it based on other divs
much more reliable
physicsrob 22:02 that couldn't be cleanly done in this situation
my page basically toggles between two layouts
taxilian 22:02 well, I wish you luck, then =]
another option would be to have two plugin instances
and share data between then
them
physicsrob 22:02 the plugin connects to a USB camera -- so that would be quite the challenge
taxilian 22:02 what? sharing data?
physicsrob 22:02 having two plugin objects connecting to the same device
taxilian 22:02 nah
piece of cake
you're on the same thread
physicsrob 22:02 hmm
taxilian 22:02 just have a static map of plugin_id to weak_ptr
weak_ptr<PluginObject>
designate one as the "primary"
then start that one first, get his "id" (just increment a counter, you won't run out in its lifetime)
physicsrob 22:02 probably more trouble than it's worth. I think I'm going to refactor so that I destroy the plugin and create a new one
taxilian 22:02 and pass that in as a param
physicsrob 22:02 there's no state that needs to be preserved... its only a matter of timing
taxilian 22:02 that's also an option
in that case, it's a good option
physicsrob 22:02 thanks for all the help tonight
taxilian 22:02 hope it was helpful
physicsrob 22:02 definitely
taxilian 22:02 sorry I don't have a better solution for the underlying bug
physicsrob 22:02 it's not your fault -- there's a lot of ugly stuff going on under the hood of these browsers :)
taxilian 22:02 that there is
welcome to my world ;-)
physicsrob 22:02 so you think it's a fluke that my destructor is getting called?
without shutdown() ?
taxilian 22:02 well, it may be a difference in how COM works between windows 7 and windows xp
but it does surprise me, eys
yes
physicsrob 22:02 okay.. well it looks like the polling to inject the object route is most likely my least evil route
thanks a bunch for coming up with it!
taxilian 22:02 I'm still trying to decide if I should be proud or ashamed
but you're welcome
physicsrob 22:02 haha
by the way -- there was a bug in 1.3 that onload wouldn't get called in webkit until there was some user input
did that ever get resolved?
taxilian 22:02 hmm. well, I know what might cause such a thing
but I'm not 100% certain
I thought we fixed it in a later version of 1.3
physicsrob 22:02 I have code in my javascript library that has a timer that calls a method of the plugin object in a try catch block every half a second until the plugin is loaded
taxilian 22:02 like 1.3.2 or something
physicsrob 22:02 to avoid the problem
probably... I think it was reported
taxilian 22:02 I remember addressing the issue
I don't remember what I did
but it must have been fixed
physicsrob 22:02 no big deal.. I was just thinking about it because it's a very similar hack
taxilian 22:02 because that's one of the tests in FBTestPlugin's test.html
physicsrob 23:02 beautiful
your hack works perfectly :)
shutdown() is called and everything looks good
taxilian 23:02 excelent
I have some thoughts on how to fix the underlying issue as well
we'll see
physicsrob 23:02 not sure if it's worth the effort. Like you said -- moving a plugin around in the DOM is a bad idea
taxilian 23:02 true; but I dislike the idea that someone can crash the browser with a FireBreath plugin just by moving things around
even if it makes things not work well, it shouldn't ever crash
so that at least I need to fix
physicsrob 23:02 true
that's actually probably just a one liner -- abort shutdown() is pluginMain is null