IRC Log Viewer » #firebreath » 2013-06-24

IRC Nick Time (GMT-7) Message
wavey 05:06 Hello everybody
Does anybody know if the FB::DetachedEvent reaches a FB::JSAPIAuto ?
If not, do you know how can I be notified (in a FB:JSAPI instance) when the user is navigating away from the plugin?
(My main concern is to release all the BrowserHost pointers, since I am waiting on a thread for user feedback)
If the user navigates away, I get an assertion error on NPP_Destroy
reichi 05:06 let me guess
the m_host assertion
the point is, there are several attributes you are not allowed to hold a non-weak-reference to
if you still do
the plugin will crash
the reason is, that the browser decides when something which has a reference to javascript is to be destroyed
and i think in NPP_Destroy some assertions a called .e.g on m_host
wavey 05:06 Yes, that's the case...
So what I am doing is the following:
reichi 05:06 use a WeakReference
wavey 05:06 I am waiting in a mutex+conditional variable, on a thread, for a user callback
therefore I am guessing the JSAPIAuto object stays alive when the user tries to navigate away
Therefore the entire JSAPIAuto with it's entire dependency tree stays locked...
reichi 05:06 there is a shutdown() method
wavey 05:06 in FB::JSAPIAuto?
reichi 05:06 // This will be called when it is time for the plugin to shut down;
// any threads or anything else that may hold a shared_ptr to this
// object should be released here so that this object can be safely
// destroyed. This is the last point that shared_from_this and weak_ptr
// references to this object will be valid
wavey 05:06 I'll give it a look
reichi 05:06 in your gnerated class
it's the one without "API"
the one derived from PluginCore
if it's only about the instance of a JSAPIAuto object
i think the destructor should be sufficient
wavey 05:06 Thanks for the pointer, I'll have a look ;)
reichi 05:06 yw
wavey 05:06 nope...
unfortunatelly destructor is not alled
I will need to forward the events from the PluginCore ...
There is no mechanism to contact all the JSAPI instances from PluginCore, right?
I tried also the JSAPIAuto::shutdown (Derrived from FB::JSAPIImpl), but it wan't fired neither
(I need to go, be back later..)
wavey 07:06 Hello everybody
I still have a question that I did not manage to solve ...
taxilian 07:06 which question is that? I've been too lazy to follow the backhistory
wavey 07:06 I lock (via mutex+conditional variable) a thread function in a JSAPIAuto instance, waiting for the user to call a function from the browser
(sorry, i was typing :P)
If the user refreshes the website, I get an exception
(NPP_Destroy assertion)
How can I be notified in order to release the conditional variable and cleanup my JSAPI instance, before the plugin unloads?
(something like shutdown in the JSAPIAuto instance)
taxilian 07:06 use the shutdown method on your PluginCore object
call a method on your JSAPI object from there
wavey 07:06 ok, then, is there any case PluginCore::createJSAPI is called twice?
taxilian 07:06 no
wavey 07:06 perfect, thanx :D
taxilian 07:06 you can also call getRootJSAPI() and then cast it, btw
with boost::dynamic_cast<YourPluginAPI>(getRootJSAPI())
wavey 08:06 ok, there was a catch...
I wad to wait for all child threads to complete...
taxilian 08:06 yes
all threads should be shut down at the end of the shutdown() call
wavey 08:06 Ps. I am still fighting with the BrowserStreams :P
I now have another issue, because my Observer class iherits from FB::DefaultBrowserStreamHandler and my BrowserProvider class
therefore there is a problem with the shared_from_this() (from DefaultBrowserStreamHandler), so I cannot attach it as an EventSink(using FB::BrowserStreamRequest::setEventSink)
anyway, I hope to solve it at some point :P
taxilian 08:06 probably is not with the shared_from_this
problem is you're holding something too long
or not shutting it down soon enough
wavey 08:06 hmm... I do this:
FB::BrowserStreamRequest req(url, "GET"); req.setCacheable(true); req.setEventSink( this->shared_from_this() ); FB::BrowserStreamPtr stream(m_host->createStream(req, false));
taxilian 08:06 you may have to destroy the req manually? I'm not sure
wavey 08:06 My guess was that shared_from_this returns somehow only the DefaultBrowserStreamHandler branch...
could that be?
taxilian 08:06 but the problem isn't the shared_from_this
shared_from_this is part of boost::shared_ptr
and I pretty much guarantee there aren't any real bugs in there
it's far too widely used and tested
wavey 08:06 ok, I'll check for req lifespan..
(I saw you did a weird trick, by putting a reference of req on itself...)
I'll give it a try
but wait...
I am listening on a mutex right after...
so I am guessing the FB::BrowserStreamRequest is not freed ...
*waiting for a mutex
(debugging again)
... now I get an assertMainThread exception, even though I call this from a new boost::thread :/
taxilian 08:06 the reference of req on itself is safe, but only if you clear it at the right time
that's because where the assertMainThread is called? That has to be called from the main thread
wavey 08:06 damn, right ...
Wow.. could it be? :P
yup... almost works
Now I am keeping a reference for too long.. ( I get the usual assertion on the NPP destructor )
Ok, I tried to use boost::shared_ptr<FB::BrowserStreamRequest> req
and call req.clear() right after the request is completed
but I still get weakHost.expired() assertion
Any ideas? (I haven't used shared_ptrs before, so I still have a bit fuzzy idea for how to use them)
taxilian 09:06 well, anywhere you are using a shared_ptr<BrowserHost> could be the culrprit
you can often help by changing those to a weak_ptr<BrowserHost>
you find out if it's still valid by doing a .lock() which will return the shared_ptr but will return a null shared_ptr if it's no longer valid
taxilian 10:06 we now have an ssl certificate for
not sure what I'll do with it, exactly
but we have one
wildcard even
yecril 13:06 <URL: > is invalid
48 Errors, 6 warning(s)
Bad value confluence-space-key for attribute name on element meta: Keyword confluence-space-key is not registered.
You can register metadata names on the WHATWG wiki yourself.
Note that URL-valued properties must not be registered as meta names but should be registered as rel keywords instead.
(affects confluence-space-url)
taxilian 13:06 yecril not sure I follow
yecril 14:06 taxilian: the pages of are defined as HTML5.
HTML5 imposes restrictions on what can be a meta attribute.
taxilian 14:06 ahh
yecril 14:06 The pages violate these restrictions; this violation is considered severe.
taxilian 14:06 are you volunteering to fix it? =]
yecril 14:06 For Atlassian?
taxilian 14:06 I have no idea how to fix it
it's possible the new confluence has it fixed
I haven't had time to update it for awhile
it's not way out of date, but it's been a few months
yecril 14:06 Well, it should be easy enough to test.
Maybe they have a recent server themselves.
taxilian 14:06 atlassian uses their own products
so certainly they have confluence servers
yecril 14:06 FTR, the footer in FB says it is 4.2.4
<URL: > is 404
taxilian 14:06 yeah; latest is 5.1.3
I'll have to find time to update
maybe I'll install the SSL cert for jira at the same time
yecril 14:06 their demo is a YouTube video; no active site?
taxilian 14:06
yecril 14:06 That makes 102 Errors :-(
taxilian 14:06 well, there you have it :-/
you could email them
yecril 14:06 I shall smear it on that very page
Looking for "invalid" gives me all invalid issues