IRC Log Viewer » #firebreath » 2011-05-19

IRC Nick Time (GMT-7) Message
nomuna 02:05 Hi everyone. I have a question and I hope there is someone who can answer it. I am using FB::script_error(message) to throw an exception inside the Plugin.
I am using a try-catch-block to catch the exception in JavaScript and display the message in as alert. It worked before Firefox 4 now I just get an NPObject error. Anybody knows how I can get the message to show?
Hi everyone. I have a question and I hope there is someone who can answer it. I am using FB::script_error(message) to throw an exception inside the Plugin. I am using a try-catch-block to catch the exception in JavaScript and display the message as alert. It worked before Firefox 4, now I just get an NPObject error. Anybody knows how I can get the message to show?
dougma 02:05 nomuna: sorry, i've never tried that. are you using the latest FB?
if you hang about, someone else may provide an answer
nomuna 02:05 I think it is not the latest... But the version I am using haven't changed so I guess it is xulrunner/firefox/npapi thing... As I said before it used to work in Firefox/Chrome before Firefox 4.
nomuna 03:05 dougma can you tell me where the FBLOG_{INFO|DEBUG|...} goes? I could dig into the project but I thought if you know it will save me some time...
nomuna 03:05 OK i guess i am alone on this... See ya all... Bye...
Chminx 03:05 Hello
I'm trying to find out more about memory management of NPIdentifier. Can anyone help ?
If Is get an NPIdentifier back from NPN_GetStringIdentifier, is it the browser taht allocates the memory for it ? And if so, how do I tell the browser to free the memory ?
man, that was some poor spelling :) let me try again. : If I get an NPIdentifier back from NPN_GetStringIdentifier, is it the browser that allocates the memory for it ? And if so, how do I tell the browser to free the memory ?
can i use the NPN_MemFree for that, even though i haven;t use the NPN_MemAlloc ? Which ofcourse makes me think taht I should be the one using NPN_MemAlloc. Yet, all the pages I found say it's the browser taht controls the lifetime of the NPIdentifier.
<confused> Any insights ?
nomuna 04:05 Is it possible that on Linux C++ exceptions are disabled in Firebreath?
I mean there was a -fexceptions was somewhere before and now it is gone?
dougma 05:05 Chminx: when the browser gets rid of your plugin then it can consider getting rid of the NPIdentifiers it gave you.
nomuna 06:05 Has anyone noticed that the string message in FB::script_error(message) stopped showing up in Firefox 4 if you catch and show using alert(message)?
Does it have anything to do to the fact that plugins are run in a plugin_container in Firefox 4? If yes how can I see the message now? Should I report it as bug?
dougma 06:05 if it works in FF 3 but not 4 then sounds like a bug to me.
nomuna 06:05 I guess I will do that.
report as a bug I mean.
dougma 06:05 have you tried the latest Firebreath?
Chminx 06:05 dougma : am I in danger of NPIdentifiers being destroyed by the browser while my plugin is still alive ??
dougma 06:05 no
Chminx 06:05 great ! :) Thank you very much
nomuna 06:05 Great. I can't create an issue on the new jira system... Tried it 2 times...
The new bug tracking system is VERY slow too...
dougma: Have ou tried it yet?
dougma 06:05 i think i last logged a bug last week, it was ok.
are you getting an error?
nomuna 06:05 Something about tokens and cookies... Dunno. Lemme see again...
Says "You may have cleared your cookies.". I didn't...
Could you report it as a bug for me?
dougma?
dougma 06:05 not right now sorry
nomuna 06:05 ok
no problem. I'll try later.
dougma 06:05 great
FireBreathBot 06:05 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-74 issue created by nomuna
nomuna 06:05 Bye all.
taxilian 09:05 Chminx: NPIdentifiers are primitives; in fact, if you look at the typedef, it's basically just a void*. you don't need to free it
you do, however, need to free the string when you get a string from the NPIdentifier
FireBreathBot 09:05 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-74 issue resolved by richard "This, unfortunately, it not a FireBreath bug. it's a browser bug. The <sarcastic>awesome</sarca..."
JIRA issue http://jira.firebreath.org/browse/FIREBREATH-74 issue closed by richard
Chminx 09:05 Taxilian : I noticed that. But I only keep NPVariants, not the string itself. So when the HasMethod comes in, I can compare my stored NPVariant witht he one passed in. I was just unsure if it's the browser that destroys my internally kept NPIdentifier and do I need to tell the browser that I'm finished with it
Chminx 09:05 the reason I ask is that in the FireBreath code I noticed this part NPIdentifier *idArray(NULL); uint32_t count; browser->Enumerate(obj, &idArray, &count); browser->MemFree(idArray);
so the NPIdentifiers that were given back by the browser are released with MemFree. Alos, the help on Enumerate says that the caller must call NPN_MemFree() on the pointer received through the identifiers parameter of a successful call to NPN_Enumerate to release the array of string identifiers when it is no longer needed.
Which would imply that I need to get rid of my internally stored NPIdentifier when I'm finished with it. Or am I missing something ?
(when I say get rid of, I mean call NPN_MemFree on it)
taxilian 09:05 Chminx: where is that code?
Chminx 09:05 just a sec
src\NpapiCore\NPObjectAPI.cpp
in size_t NPObjectAPI::getMemberCount() const
taxilian 09:05 !findfile NPObjectAPI.cpp
FireBreathBot 09:05 Found 1 matching file(s) in the master branch. First 1 are:
src/NpapiCore/NPObjectAPI.cpp http://goo.gl/IXkVw
taxilian 09:05 ahh. that's a special case
notice that it isn't an NPIdentifier
it's an NPIdentifier*
in other words, it's an array of NPIdentifiers
Enumerate returns an array of NPIdentifiers, and since it was allocated by the browser on the heap it needs to be freed with MemFree (NPN_MemFree)
a normal NPIdentifier is not allocated on the heap, it's just on the stack
so you don't need to free it
Chminx 09:05 ah, I see
cool, thank you for that
taxilian 10:05 yw
linearray 10:05 did I understand FB events correctly: if I fire an event all DOM elements that have an event listener on that event will process it
and if I want only some of them to process it, I need to make separate events
taxilian 10:05 linearray: yes
pretty much
linearray 10:05 k
linearray 10:05 I'll shuffle around the docs on that a bit
taxilian 10:05 cool
linearray 10:05 so, when using FB_JSAPI_EVENT, I shall not prefix the event with 'on'
why? :)
is it done automatically?
taxilian 10:05 yes
it is done automatically
linearray 10:05 cool
taxilian 10:05 to avoid any confusion with people who don't realize that it needs to be there =]
also so that you can do fire_event instead of fire_onevent
I mean, it's a preprocessor macro… there is only some much I can do =] removing "on" from the beginning of a string is not in the cards
linearray 10:05 ok, but then in JS i need to add the listener with 'onevent'
right?
taxilian 10:05 on IE, yes
or if you do a "old-style"
addEventListener you omit "on"
linearray 10:05 hm I see
this is confusing :)
taxilian 10:05 heh. not my fault =]
attachEvent uses "on", addEventListener does not
if you assign the handler as a property (plugin.onevent) then you need on on any browser, but you can only use one of those
linearray 10:05 so what is the 'canonical' name of an event... with or without 'on'
probably without
taxilian 10:05 define "canonical"
linearray 10:05 like, internally used
taxilian 10:05 with "on"
linearray 10:05 hehe
taxilian 10:05 and addEventListener prepends it
that's why previously you had to have it
but with the new macro it's easier to prepend it in the macro; less confusing, less room for mistakes
linearray 10:05 ouch
taxilian 10:05 just all has to do with the way that browsers deal with them natively; I tried to copy it as closely as possible
you could of course roll your own event system in your plugin if you wanted to, just to make it all the same =]
linearray 10:05 I'd rather not :)
taxilian 10:05 =]
how do you like the new event firing convention, though? the macro?
linearray 10:05 so, when using attachEvent, ONLY in IE I need to specify 'on'?
or in all browsers
or does it only exist in IE :)
taxilian 10:05 attachEvent always you need "on"… but it only works in IE
linearray 10:05 k
taxilian 10:05 addEventListener, on the other hand, doesn't exist on IE until IE9, where it exists and fails silently to do anything useful with an ActiveX control
so don't use addEventListener if attachEvent exists
linearray 10:05 I very much like the event system, just need to grasp it yet :)
hmm, so what if I add the event listener not to the plugin element, but to any other element
would that work?
taxilian 10:05 what do you mean?
linearray 10:05 I guess what I mean is, if I fire an event in the plugin, is it only fired in document.getElementById("plugin") or all across the DOM?
taxilian 10:05 it is only fired to handlers attached directly on that plugin object
it does not bubble
linearray 10:05 ok
is bubble a technical term? :)
taxilian 10:05 strangely, yes =]
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-bubbling
linearray 10:05 nice
linearray 10:05 It'd be totally awesome if the menu sidebar expanded automatically when you click on an entry
taxilian 10:05 heh. yeah, you get what you get with confluence, though
linearray 10:05 yep
taxilian 11:05 linearray: looks good =] thanks for doing that
sabotaged|wk 11:05 ugh still struggling with this bundle stuff. thought i had it working, but it wasnt really. so to verify the steps i need to do are a) copy the files i want to be in my bundle to ${CMAKE_CURRENT_BINARY_DIR}/bundle, then make sure to use set_source_files_properties on each of those files?
oh, and make sure they get added to ${SOURCES} ?
sabotaged|wk 12:05 ok there
that took way too long
will make sure to document
taxilian 12:05 you shouldn't need to copy the files
just do set_source_files_properties on each of the files; cmake should put them in place during the build
I tihnk
FireBreathBot 13:05 Commit dfc1643 on firebreath-1.5 by Richard Bateman: "Changed ints from 64 to 32 on uploadqueue" http://goo.gl/zkvZF
Commit dfc1643 on master by Richard Bateman: "Changed ints from 64 to 32 on uploadqueue" http://goo.gl/zkvZF
FireBreathBot 15:05 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-75 issue created by richard
Commit 6b19160 on firebreath-1.5 by Richard Bateman: "FIREBREATH-75: Fixed potential conflict w/ Mac OS libs" http://goo.gl/ZMkSJ
Commit 952fb98 on firebreath-1.5 by Richard Bateman: "Fixed issue where files not always regenerated when needed" http://goo.gl/Iy7O7
Commit 6b19160 on master by Richard Bateman: "FIREBREATH-75: Fixed potential conflict w/ Mac OS libs" http://goo.gl/ZMkSJ
Commit 952fb98 on master by Richard Bateman: "Fixed issue where files not always regenerated when needed" http://goo.gl/Iy7O7
starakaj 17:05 heya
I don't support anyone's got time for a dll question
I'm running into a problem where people running windows & can't run my plugin
because they don't have d3dx9.dll, which is apparently optional
& = 7, BTW
anyway, best practices here seems to be to run the directx installer silently without telling the user
so I guess I have to bundle that into the plugin installer somehow
my question is, well, how do dat?
http://wix.sourceforge.net/manual-wix3/install_directx9.htm
relevant?
taxilian 19:05 starakaj: Never tried, but seems possible
What os are they on?
taxilian 20:05 starakaj: looking at the link more, that looks like a valid way to do it
FireBreathBot 21:05 Commit c54b9ee on firebreath-1.5 by Richard Bateman: "Fixed bizarre file generation bug w/ cmake on windows" http://goo.gl/AmVWl
Commit 16d84e6 on firebreath-1.5 by Richard Bateman: "Fixed minor glitch in JSAPIProxy" http://goo.gl/gnZbj
Commit e5d7d68 on firebreath-1.5 by Richard Bateman: "Type change in UploadQueue" http://goo.gl/67ZnI
Commit c54b9ee on master by Richard Bateman: "Fixed bizarre file generation bug w/ cmake on windows" http://goo.gl/AmVWl
Commit 16d84e6 on master by Richard Bateman: "Fixed minor glitch in JSAPIProxy" http://goo.gl/gnZbj
Commit e5d7d68 on master by Richard Bateman: "Type change in UploadQueue" http://goo.gl/67ZnI
taxilian 21:05 nirvdrum: you seen this yet? http://code.google.com/p/phantomjs/
nirvdrum 21:05 I hadn't. I'll have to check that out.
taxilian 21:05 you may find some nice uses for it with mogotest; my primary interest is that it looks like it can actually load NPAPI plugins...
in a headless manner
and script them
nirvdrum 21:05 Wow. That'd be nice.
taxilian 21:05 yeah
taxilian 22:05 nirvdrum: I just used it to load the FBTestPlugin test page…. all the tests passed
all headless
FireBreathBot 22:05 JIRA issue http://jira.firebreath.org/browse/FIREBREATH-76 issue created by dougma
dougma 22:05 minor patch on the way
taxilian 22:05 excellent =] those are the kinds of issues I like… the ones I dont' have to fix myself =]
dougma 22:05 i am fiding fb-68 hard to solve properly...
taxilian 22:05 yeah… that's one reason I haven't done so yet =] whats the problem?
dougma 22:05 basically i can't work out where to add the "this" parameter and resolve it to the necessary parameter in a x-platform way
taxilian 22:05 you're just concerned about asynchronous calls, right?
the ones going through the delegate?
dougma 22:05 yes.
taxilian 22:05 !findfile JSObject.h
dougma 22:05 how do i get an IDispatch in there for example?
FireBreathBot 22:05 Found 1 matching file(s) in the master branch. First 1 are:
src/ScriptingCore/JSObject.h http://goo.gl/ThAY9
taxilian 22:05 you don't
you don't want to
you don't need to
https://github.com/firebreath/FireBreath/blob/master/src/ScriptingCore/JSObject.h#L100
getHost()->getDOMElement() will return a FB::DOM::ElementPtr for the DOM element you need
!findfile Node.h
FireBreathBot 22:05 Found 2 matching file(s) in the master branch. First 2 are:
src/ActiveXCore/AXDOM/Node.h http://goo.gl/uqL4A
src/ScriptingCore/DOM/Node.h http://goo.gl/Vh7ks
dougma 22:05 but that doesn't actually work
taxilian 22:05 why not?
dougma 22:05 i don't know, but in IE it's not the dom element, it's the com control
taxilian 22:05 !find getJSObject
FireBreathBot 22:05 Found 1 possible matches. Displaying 1
/^ virtual FB::JSObjectPtr getJSObject() const { return m_element; }$/ (f) found in src/ScriptingCore/DOM/Node.h: http://goo.gl/pCJdO
taxilian 22:05 what do you mean by the COM control? it has always been the DOM element for me… I can request attributes from it, for example
unless that's broken on IE9, I suppose
but I don't think it is
if you call getJSObject() on getDOMElement() it returns the same IDispatch that the method you were trying to add returns
dougma 22:05 (i'm using ie8 so far) DOM properties (like "id") aren't there
that's when i noticed.
taxilian 22:05 you were fetching it using https://github.com/dougma/FireBreath/commit/16f1bcd7c03151d5e8e5ea5ea6e201447a01fabb#L0R108 getExtendedControl(), right?
FireBreathBot 22:05 16f1bcd by dougma: FIREBREATH-68 set this for ax & npapi callbacks http://goo.gl/g3RD2
dougma 22:05 yes but old getDOMElement does another queryinterface...
taxilian 22:05 it may… doesn't matter. that's not what it returns when you call getJSObject()
it returns the JSObject that you created the object from
which has an IDispatch in it
which is the one you passed in
dougma 22:05 sorry, one sec (at work here)
taxilian 22:05 if you're not able to request ID from that that is another bug; I was certain I'd done that recently-ish
where you located?
dougma 23:05 back. i'm gmt+8 :)
taxilian 23:05 which is...?
dougma 23:05 .au
taxilian 23:05 Australia?
dougma 23:05 indeed
taxilian 23:05 cool
don't know many FireBreath users from there yet
dougma 23:05 if you build it, they will come :)
taxilian 23:05 heh. it's interesting to watch the growth of this project; often when things seem the quietest they are growing the most, based on the web analytics
anyway, try that using the JSObjectPtr from getDOMElement(); I think it'll surprise you
it should work fine
dougma 23:05 ok, will go back try that. ta.
meanwhile i have some other patches
taxilian 23:05 and thanks for being one of the few that actually fixes their own problems instead of just expecting me to do everything =]
dougma 23:05 no probs. i know activex plugin interface quite well
we are porting a control to npapi so...
learning. :)
taxilian 23:05 really? awesome! that's where I fall shortest
so interesting problem / bug we still have.. .maybe you would have an idea
when InPlaceDeactivate gets called, if we don't release all IDispatch objects we have from javascript (callbacks, etc) then Close is never called
which means that if you move a FireBreath plugin around in the DOM it will invalidate any and all JSObjectPtr objects that are held anywhere, else the plugin doesn't shut down
because IE never calls Close
never calls SetSite to NULL or anything
dougma 23:05 IE is very tardy on calling close.
taxilian 23:05 it's not a question of tardy… it never happens
dougma 23:05 mmmm.... not seen it happen exactly like that
taxilian 23:05 if you look at FBControl.h and comment out the line in InPlaceDeactivate that invalidates all objects on the host you can see it for yourself =]
!findfile FBControl.h
FireBreathBot 23:05 Found 2 matching file(s) in the master branch. First 2 are:
gen_templates/FBControl.htm http://goo.gl/gXezA
src/ActiveXCore/FBControl.h http://goo.gl/a0z6T
taxilian 23:05 https://github.com/firebreath/FireBreath/blob/master/src/ActiveXCore/FBControl.h#L362
that one
anyway, if you have some time and want to look at it, it'd sure be nice to fix that
dougma 23:05 i've noticed that moving npapi in the dom has problems too
but is that a npapi limitation?
taxilian 23:05 there is a ff4 bug I know of that can be triggered by that
but no, it shouldn't be a problem… just is
dougma 23:05 move it and it gets destroyed
taxilian 23:05 hmm. that may depend on the browser implementation
dougma 23:05 not desirable anyway
taxilian 23:05 I think I have seen that happen, though, now that you mention it
yeah; my advice is generally to put it in a div and absolute position if you need it to move
dougma 23:05 mmm
we'll be revisiting that stuff soon (moving plugins in the dom)
will take a closer look at FBControl.h then i think
taxilian 23:05 well, let me know if you have problems and I'll help as I can
I'm GMT-6, so… =]
dougma 23:05 yes... but irc is good. :)
taxilian 23:05 yep
and the forums are there as well
dougma 23:05 ok... issues to log, patches to make
taxilian 23:05 cool.
dougma 23:05 oh btw, great project. :)
taxilian 23:05 thanks =] I enjoy it
I have spent a lot of time on it
dougma 23:05 that's obvious
this is hard-won knowledge
npapi and activex are just total quirks-ville
taxilian 23:05 it's ridiculous how hard-won… when you consider that http://npapi.com/tutorial is one of the best sources for info on NPAPI available, and I wrote it 2 years ago and that's still the case… and it's not really even that fantastic of an article
yeah
NPAPI is a lot more straightforward to me; activex still gives me grief sometimes
but FireBreath does a pretty good job of abstracting it away