IRC Log Viewer » #firebreath » 2011-01-14

IRC Nick Time (GMT-7) Message
DFUN 04:01 Can I use FB to read from an URL synchronously?
I need to get a few lines of text
iaincollins 05:01 Do you need to do that cross platform?
I am using WinHTTP (on Windows) and libcurl (on Mac) to do that (only not curl cross platform as it wouldn't play nicely building in VS with FB, because it was being annoying)
I think taxilian was talking about implimenting something to make HTTP calls from FB easily though, but I don't know if that's in 1.4 or not (too many improvements to keep track of 8) so might we worth checking with him
DFUN 07:01 extra long meeting...
thanks, Iain
iaincollins 07:01 boo (to meeting)
taxilian 08:01 DFUN: You don't want to do synchronous calls on the main thread and on other threads you can block on waiting for a signal
iaincollins: Wb. Glad you're feeling better
No, it didn't make it into 1.4
iaincollins 08:01 thanks :)
DFUN 08:01 hm... ok. I will start a stream for these two lines on monday. Might even be easier than compiling libcurl... and sounds more sensible on top of that
goodbye
taxilian 09:01 amackera: any ETA on that window thing, or should I do it?
FB_GitHubBot 09:01 FireBreath: master Richard Bateman * 1c94511 (3 files in 2 dirs): Minor tweaks and format changes - http://bit.ly/egrVJ6
taxilian 09:01 is there anything other than the "easy HTTP request" feature that I haven't gotten to that I promised to do for 1.4?
iaincollins 09:01 not that I can recall, I assumed it was unrealistic to expect that as well (just maybe a nice thing to put on a wishlist)
suspect this is more done than people have had time to document :)
taxilian 10:01 I'm debating; I actually need that feature soon
so I'll definitely have it done soon
just debating if I should slip it in
I wouldn't consider it, but I did say it would be there...
amackera 10:01 taxilian: I'm firing up my VM right now to fix that bug
taxilian 10:01 amackera: awesome, thanks!
iaincollins 10:01 I've not actually started back on my project yet (as am only back properly as of yesterday, as managed to get ill right away again), looking forward to starting on FB again next week
taxilian 10:01 iaincollins: have you looked at the changelog for 1.4? it's very long… :-P
iaincollins 10:01 I'm scared :P
taxilian 10:01 well, that's the reason it's a beta not an RC
I want to give it a little extra testing
iaincollins 10:01 very good plan I think
I will try it out next week
taxilian 10:01 cool
sorry you had to spend your holiday being sick
iaincollins 10:01 I will finish some things I am doing on 1.3 (just to make sure the kinks are out)
yeah bummer, thanks
our fairly boring release of the plugin has been helpful, lots of testing has been nice
and now we are getting requests from other teams for doing things
taxilian 10:01 great!
any serious issues?
iaincollins 10:01 no, none at all
amackera 10:01 nice :D
iaincollins 10:01 only issue has been to do with ClickOnce detection in FireFox
amackera 10:01 Strangely, I have had almost no support requests also...
iaincollins 10:01 which goes a bit funny if you have the plugin for that installed then some dependancy for it gets *uninstalled*
and I can't see anyway you can check for that in JS.. yet
(it downloads the clickonce app, but then it fails to run succesfully) but not given out hope
taxilian 10:01 huh
iaincollins 10:01 but zero issues with FB on any platform
taxilian 10:01 that's annoying
would really appreciate any install related code you could contribute back to FB, btw
iaincollins 10:01 oh yeah will do for sure
will do that for 1.4
taxilian 10:01 one of the new features of 1.4 is a new security model for JSAPI; you might find it useful to lock down your plugin so it can only be used on your company website
and not elsewhere
iaincollins 10:01 oh cool
taxilian 10:01 could be a potential security risk, since your plugin gives out network info, no?
iaincollins 10:01 yeah, I actually do a domain check right now
*looks to see how*
amackera 10:01 iaincollins: Does ClickOnce work with chrome?
taxilian 10:01 cool. You'd do the same thing here, but you'd use that to determine a SecurityZone and pass that in when you create your JSAPI object
iaincollins 10:01 cool
FYI, I currently do:
std::string url = this->m_host->getDOMWindow()->getLocation();
then:
if (boost::starts_with(url, "http://www.talktalk.co.uk/selfhelp/") || some other allowed URL (staging/dev/etc)
taxilian 10:01 easier way to do it is to use FB::URI
but that's basically what I expect
iaincollins 10:01 oh!
taxilian 10:01 it's probably also new in 1.4; I forget
hmm
iaincollins 10:01 *notes*
taxilian 10:01 there are some things missing from that changelog
iaincollins 10:01 I can imagine :)
I got halfway through the chat search... something to do at the weekend...
taxilian 10:01 awesome
huh. yep, URI is new in 1.4
better add that...
iaincollins 10:01 hehe
taxilian 10:01 hmm. need to document it first
amackera 10:01 taxilian: are we committing changes to master or to the 1.4 branch?
taxilian 10:01 1.4
well, technically it doesn't matter, since you'll just be cherry-picking the commit into the other
but ideally 1.4 at this point
zmichl 10:01 hi guys
taxilian 10:01 how're stuff, zmichl?
amackera 10:01 hey
zmichl 10:01 I'm playing with my FB plugin and I observed that if I disable and re-enable the plugin in FF, it doesn't work anymore until I restart FF
is any way to fix it?
taxilian 10:01 I'm pretty sure that's a FF thing
how are you disabling it?
zmichl 10:01 in addon manager
taxilian 10:01 yeah, that's a firefox thing
zmichl 10:01 Tools -> Add-ons -> Plugins
taxilian 10:01 at least, AFAIk
don't think there is anything we can do about it
does the plugin even load?
or acts like it isn't even detected?
zmichl 10:01 hmm, so plugin's object is undefined until html page is reloaded
taxilian 10:01 try using JS to do navigator.plugins.reload(false)
zmichl 10:01 navigator.plugins.refresh() ? :)
no success either
iaincollins 10:01 hmm have you tried removing the plugin element and adding it on the page?
(if that's an option)
*adding it back to, I mean (e.g. reinserting a valid <object> element)
amackera 10:01 Hmm firebreath-1.4 contains build errors currently for the example plugins
"pluginGuiEnabled" identifier not found
taxilian 11:01 really? that's weird.. let me try it
was working yesterday, unless somehow I didn't get everything pushed...
amackera: you're on firebreath-1.4?
zmichl 11:01 iaincollins: how can I reinsert it?
iaincollins 11:01 for example (just for simplicity) assuming it's in a parent div with the ID "wrapper"...
could try:
document.getElementById('wrapper').innerHTML = ""; // Remove the existing <object> / plug-in instance
amackera 11:01 taxilian: firebreath-1.4, that's right
iaincollins 11:01 document.getElementById('wrapper'.innerHTML += '<object id="myPlugin" type="application/x-myplugin"></object>';
taxilian 11:01 amackera: it builds for me...
at least on mac
let me clone a clean copy on windows
also builds on linux
iaincollins 11:01 zmichl: I currently remove/re-add references to the plug-in to allow in place upgrades, I also call: if (navigator.plugins) { navigator.plugins.refresh(false); }
zmichl 11:01 iaincollins: ok, I'll try it later, now I'm going away. Thanks for advice ;) bye
iaincollins 11:01 np, good luck
amackera 11:01 taxilian: I am building on windows
taxilian 11:01 yeah, I'm working on getting there...
FB_GitHubBot 11:01 FireBreath: master Richard Bateman * 44a1408 (2 files in 2 dirs): Fixed doxygen paths - http://bit.ly/eGpB9G
amackera 11:01 NpapiPluginWin:66 if(pluginGuiEnabled() && pluginMain->isWindowless())
taxilian 11:01 amackera: you sure you updated? mine builds fine
amackera 11:01 positive, i did a fresh checkout
taxilian 11:01 pluginGuiEnabled was added yesterday in PluginInfo.h
wait...
no, I'm getting a different error, but not that one
trying with a fresh checkout
iaincollins 11:01 have a great weekend all
taxilian 11:01 amackera: that's weird; I can see if now that I did a fresh checkout. very weird. hang on, I'll have it fixed momentarily7
amackera 11:01 sure
maybe a lingering cmake thing?
taxilian 11:01 no, just a missing include
FB_GitHubBot 11:01 FireBreath: firebreath-1.4 Richard Bateman * 9a310ac (1 files in 1 dirs): Fixed build error with missing include file - http://bit.ly/eXvKn3
amackera 11:01 ah
thx
taxilian 11:01 thanks for letting me know
gotta figure out why my normal working tree isn't in sync like I thought
FB_GitHubBot 11:01 FireBreath: firebreath-1.4 Richard Bateman * 465782f (2 files in 1 dirs): Added docs for FB::URI
FireBreath: firebreath-1.4 Richard Bateman * 1c08eb6 (3 files in 2 dirs): Refactored DefaultBrowserStreamHandler to its own file
FireBreath: firebreath-1.4 commits 9a310ac...1c08eb6 - http://bit.ly/dSmyct
FireBreath: firebreath-1.4 Richard Bateman * 8e2d737 (3 files in 2 dirs): Minor tweaks and format changes - http://bit.ly/hDiAto
taxilian 11:01 there we go. much better
amackera 11:01 builds properly now
taxilian 11:01 excelent
amackera 11:01 by the way we're on TV right now
taxilian 11:01 tophatmonocle?
amackera 11:01 there's an interview going on behind me
yeah haha
taxilian 11:01 awesome
put in a good word for FireBreath :-P
amackera 11:01 haha, :D
i don't think i'm going to get interviewed
taxilian 11:01 tell Matt to put in a good word for us, then =]
amackera 11:01 Definite breakage in Chrome
Does windows chrome run in OOPP?
taxilian 11:01 yes
amackera 12:01 Visual studio debugger doesn't catch the crash... wtf...
taxilian 12:01 hmm.
amackera 12:01 Okay well i have the fix we talked about last night
but that's certainly not the issue we're seeing in chrome
I'm going to commit this fix, I need to work on other things for a while
I can take a look again later
taxilian 12:01 hmm. interesting
how do you reproduce the issue?
amackera 12:01 just open FBControl.htm in chrome in windows for FBTestPlugin
taxilian 12:01 that easy? that's not a good sign
ok
I'll look at it
amackera 12:01 sorry i can't be more help at the moment
taxilian 12:01 sok
amackera 12:01 To push to a remote branch: git push origin firebreath-1.4
is that right?
taxilian 12:01 right
FB_GitHubBot 12:01 FireBreath: firebreath-1.4 Anson MacKeracher * ffa8d67 (3 files in 2 dirs): Merge branch 'firebreath-1.4' of github.com:firebreath/FireBreath into firebreath-1.4 - http://bit.ly/i3bWGA
amackera 12:01 Oh man, I think I did that wrong again
taxilian 12:01 looks right to em
me
amackera 12:01 Is it okay that I merged changes?
taxilian 12:01 yeah, that's fine
huh;
except I don't see your changes
amackera 12:01 they are in firebreath-1.4
taxilian 12:01 I'm looking at firebreath-1.4
I only see your merge
amackera 12:01 https://github.com/firebreath/FireBreath/commit/146a37fe4e7f5b35037b1d7227fe91e2ae34b4c6
that's the actual change
taxilian 12:01 oh, there it is
ok
I'll cherry-pick it back to master
sabotaged|wk 12:01 so when is a bad time to call ScheduleOnMainThread?
i'm getting a crash when i'm calling it around shutdown
taxilian 12:01 hmm. If you call it while you're shutting down that could be a problem
where are you calling it from?
sabotaged|wk 12:01 worker thread
taxilian 12:01 and what version?
sabotaged|wk 12:01 1.4 from a couple of days ago
taxilian 12:01 hmm. shouldn't crash, I wouldn't expect… interesting question
sabotaged|wk 12:01 the call stack is useless, but i know it's my worker thread
taxilian 12:01 why is the call stack useless? what actually causes the crash?
sabotaged|wk 12:01 maybe i'll try VS2008, i know VS2010 has had some debugger issues with callstacks
taxilian 12:01 null ptr?
sabotaged|wk 12:01 there's no user mode call frames
oh wait
there's one for my plugin but its greyed out, weird
taxilian 12:01 how is your thread accessing the BrowserHost?
you aren't using any raw poitners, are you?
sabotaged|wk 12:01 no its a shared_ptr
maybe i should use weak?
taxilian 12:01 definitely should be a weak_ptr, yes
sabotaged|wk 12:01 ok
taxilian 12:01 but that won't neccesarily fix the issue
hypothetically if you make a call after shutdown() is called on the browser it should ignore it...
but there may be a race condition
sabotaged|wk 12:01 so where else should i be using a weak_ptr for browserhost?
taxilian 12:01 anywhere that might be around longer than the plugin object
same for using a weak_ptr to your JSAPI objects
or your plugin object itself
sabotaged|wk 12:01 ok
hmm, 2008 callstack is not helpful either
taxilian 12:01 the idea being that you don't want to keep the browserhost from being released
sabotaged|wk 12:01 yeah
taxilian 12:01 have you tried shutting down your thread from the plugin destructor?
sabotaged|wk 12:01 i do shutdown this thread from a destructor, but it isn't getting called before the crash. i'll have to check why
taxilian 12:01 which destructor?
the plugin or the API?
sabotaged|wk 12:01 i'll have to check, there is a few layers of composition of objects going on
taxilian 12:01 you may want to update to the latest 1.4, or at least to beta 1. there is a fix that gives you more control of the lifecycle of your plugin API objects
sabotaged|wk 12:01 the plugin is holding a reference to the composition of objects that eventually destructs my worker thread
my API has a weak ptr to that composition of objects
is this the right way to do it?
taxilian 12:01 ok; so your plugin destructing should cause the worker thread to go away?
sabotaged|wk 12:01 yes
taxilian 12:01 can you make your plugin destructor block until the threads are gone?
sabotaged|wk 12:01 yeah that should be possible
i'll try ti
taxilian 12:01 ideally nothing should be trying to do anything once the plugin destructs
sabotaged|wk 13:01 hmm
is ScheduleOnMainThread(shared_from_this(), boost::bind(&RemoteService::doChecks, shared_from_this())) ok?
it looks like the ref count for that shared_ptr is increasing all the time but never decreasing
after ScheduleOnMainThread is called
so my object isnt destructing, and hence stopping the thread
not stopping the thread i should say
taxilian 13:01 hmm
let me think on that a few minutes
sorry, was fixing some wiring
I love my UPS system… 3 computers, 2 switches, and an Apple TimeCapsule all continued running on battery power for nearly 30 minutes while I had the breaker shut off
taxilian 14:01 sabotaged|wk: I think I know what is happening with your unreleased references
working on a fix
sabotaged|wk 14:01 sweet
taxilian 14:01 nothing like changing one of the most fundamental APIs just before a release… :-P
but this needs to happen
shouldn't break anything, though
just adding a return value
what browser are you seeing this on? all?
sabotaged|wk 14:01 i'm trying it on firefox right now
windows
i can try it on another if you want
taxilian 14:01 no, that's okay
just verifying
hmm. to really do this right, this could take a little work
glad you brought this up
https://developer.mozilla.org/en/NPN_PluginThreadAsyncCall <— inherent race conditions during shutdown
I can fix it, but it'll take a few minutes
I'll have to add an extra layer of abstraction and track the calls that have been made
taxilian 15:01 hmm. I don't see any way of doing this without leaking data
this is frustrating
granted, it would only leak data in cases where before it would have prevented things from shutting down, which would be a much worse leak
taxilian 16:01 I have literally been checking out the chromium source for the last 3 hours
and it's still going
I have a good fast connection
jtojanen 16:01 taxilian: i saw that you had talks about some shutdown issues??
taxilian 16:01 yeah
interesting issue
race condition on async calls on shutdown
jtojanen 16:01 use of shared_from_this is not safe inside destructor
taxilian 16:01 right
that I know
jtojanen 16:01 should use enable_shared_from_this2 instead of enable_shared_from_this to avoid that limitation
also works inside constructor
taxilian 16:01 enable_shared_from_this2 allows that?
really?
never heard of this
jtojanen 16:01 yep
magic
taxilian 16:01 still doesn't solve (or relate to) this problem
but very cool
jtojanen 16:01 it has delayed attachment of impl
taxilian 16:01 hey, on ActiveX, where is the best place to signal shutdown?
when I put it in the destructor, sometimes the destructor doesn't get called (when IE is closed it is never called)
the destructor of FBControl.h
but sometimes it seems that the window goes away and comes back
jtojanen 16:01 that is refresh
DllCanUnloadNow defines unload moment ; final shutdown
taxilian 16:01 I need something specific to the plugin instance
jtojanen 16:01 there is still some cycles that i havent discovered
setsite(NULL)
is the moment then
taxilian 16:01 but that gets called at the beginning as well
how do I tell the difference?
well, setClientSite does at least
jtojanen 16:01 in the begin it gives you "access point" and at the end it tells to release everything that you have used/received
by defining NULL
taxilian 16:01 hmm
at one point, I was getting a SetClientSite(NULL) during startup
and then later I'd get the real one
now I'm getting the real one, but never getting a NULL
jtojanen 16:01 that should not happen
taxilian 16:01 I'm delighted to hear it =] unfortunately, it is happening…. :-P
jtojanen 16:01 is it happening with one of examples?
taxilian 16:01 FBTestPlugin
I always develop on FBTestPlugin
jtojanen 16:01 okey; good to know
taxilian 16:01 I have changes in my local tree, but they shouldn't affect anything on ActiveX (at least not this part)
hmm. makes me think there is a refcount problem somewhere
jtojanen 16:01 and those last changes that i made should have fix some of the cycles
must be
it is difficult to fix because some many CComQIPtrs are kept as class members
and classes have strong shared_ptr cycles
taxilian 16:01 hmm. true. Ooohh… thought
does setClientSite(NULL) not happen until the refcount hits 0 and the class is cleaned up?
jtojanen 16:01 before refcount hits 0
because caller has at least one ref
order is that setclientsite(NULL) , and then container releases plugin
taxilian 16:01 hmm. actually, what I was thinking doesn't apply
so theoretically, any IDispatch objects that we pass to IE should get released, right?
so that should then release the CComQIPtrs that hold FBControl
jtojanen 16:01 yep
taxilian 16:01 FBControl doens't hold any of them
so there should not be a circular ref
jtojanen 16:01 * will check source *
taxilian 16:01 hmm.. except for the ActiveXBrowserHost
which holds a ref to the FBControl
which holds a shared_ptr to ActiveXBrowserHost
for just this reason, there is a shutdown() method on the BrowserHost
but it is never getting called
jtojanen 16:01 do you get call to setclientsite(null) during shutdown?
taxilian 16:01 it should be called right before m_host->reset() (that you added), but that whole branch setClientSite(NULL) never gets called
no
jtojanen 16:01 damn
taxilian 16:01 exactly
jtojanen 16:01 then there is loop
taxilian 16:01 what would prevent that from being called?
I would have thought that would be a "I'm closing you" signal from the browser
jtojanen 16:01 ref to element e.g
taxilian 16:01 wait… would holding a reference to the "extended control" do that?
jtojanen 16:01 yes
that is outer part of aggregate
taxilian 16:01 I assume that holding an extra reference to m_spClientSite could as well?
jtojanen 16:01 no
taxilian 16:01 ok; I can do that, then
I've been holding a reference to the element; didn't know that would do that
figured I could just release it when shutdown signalled
guess I'll have to query it each time
jtojanen 16:01 true
taxilian 16:01 let me try that and see if it fixes the issue
jtojanen 16:01 i will check logs and if needed i can track that tomorrow also the windowsless issue
taxilian 16:01 okay
hopefully that'll get me where I need to be
thank!
thanks!
you came at just the right time =]
jtojanen 16:01 later
thanks
taxilian 16:01 see you
taxilian 17:01 jtojanen: First-chance exception at 0x7767b727 (KernelBase.dll) in iexplore.exe: 0x8001010D: An outgoing call cannot be made since the application is dispatching an input-synchronous call.
taxilian 17:01 I think this may be what is killing it; it's interfering with calls from the browser
FB_GitHubBot 23:01 FireBreath: firebreath-1.4 Richard Bateman * fe026f6 (13 files in 5 dirs): Fixed race condition between async calls and plugin shutdown ...
FireBreath: firebreath-1.4 Richard Bateman * 6ece42b (1 files in 1 dirs): Fixed warnings
FireBreath: firebreath-1.4 commits ffa8d67...6ece42b -
FireBreath: master Richard Bateman * 6da7d2c (13 files in 5 dirs): Fixed race condition between async calls and plugin shutdown ...
FireBreath: master Richard Bateman * 3d5cb66 (1 files in 1 dirs): Fixed warnings
FireBreath: master commits 880f3d6...3d5cb66 - http://bit.ly/hwJz9v