IRC Log Viewer » #firebreath » 2011-03-08

IRC Nick Time (GMT-7) Message
saiaman 01:03 hello
is everyone going well ?
maybe sleeping i think :)
so good night
nitrogenycs 04:03 hey guys
has anybody encountered a problem when trying to access the 'tagName' property on your <object> element?
it always returns undefined in my case
it should return 'object' really
is this a problem with firebreath?
It happens only in NPAPI defined browser
IE is fine
nitrogenycs 04:03 ok, I debugged a bit and the HasProperty/GetProperty methods of NPJavascriptObject are called
they return false and undefined respectively
I see there are explicit checks for "addEventListener"
and "toString" etc
now I guess there are a few more standard names such as "tagName" that'd need to be added. However, I wonder if there isn't a browser-supplied fallback function for these "special" names
after all there are a looooot of them:
without them the domelement doesn't behave as expected with many external libraries
this is with latest git btw
nitrogenycs 06:03 hmm, I wonder if this could be solved by using NpapiBrowserHost::getDOMElement and relaying the functions there
nitrogenycs 06:03 hmm, obviously this results in endless recursion :)
nitrogenycs 07:03 hmmm, maybe I should try to call the getproperty on the class of the element in this case... like done here:
damn, recursion again. Is there no way to get at the non-overloaded value of a property?
nitrogenycs 08:03 hmm, one more hint
when I add a tagName thing like shown here I can get at the right value "OBJECT"
my problem is that that NPJavascriptObject::GetProperty overrides NpapiBrowserHost::GetProperty for the base dom element somehow. So when you try to get the "tagName" attribute, it will query the jsapi which will return undefined since there is no "tagName" attribute in it. Now I want to get the dom elements "tagName" instead, but I can't find the right function to retrieve it. I always end up in the same GetProperty function where I already
nitrogenycs 09:03 DUH
adding it to the list of reserved names in JSAPIAuto does the trick
nitrogenycs 09:03 ok, sent a mail to the list where I state the problem against along with a possible solution
*end of monologue* :)
johnd_ 09:03 Hi, I have 2 quick questions on onWindowDetached()...
1. when it's called does the window still exist?
2. what am I supposed to return from this method>?
taxilian 10:03 johnd_: 1 - yes. 2 - doesn't matter
johnd_ 10:03 the event handlers all return a bool... is that just in case or is there a general rule what to return on the ones that matter?
taxilian 10:03 johnd_: the way the event system works is you turn true if you handled the event, false if not
in the case of detachedevent, it doesn't really matter what you return
but that's an exception to the rule is all
johnd_ 10:03 ah, good to remember. I think I always return true but only by guessing or following demo code
taxilian 10:03 if you're handling a platform event you may want to let the platform do its thing as well
for example if you return false on a RefreshEvent the underlying object will try to draw
taxilian 10:03 nitrogenycs: sorry I wasn't around; I could have answered your question
saved you some time
neilg_ 10:03 How dare you sleep! ;)
taxilian 10:03 I know. it's a bad habit I picked up somewhere
neilg_ 10:03 I blame the parents. Kids these days... lol
taxilian 10:03 I'm trying to break it, but the withdrawal symptoms are terrible
neilg_ 10:03 I don't think there's a patch for it yet but there are pills you can take!
taxilian 10:03 lol
neilg_ 10:03 I hear it also comes in liquid form too...
taxilian 10:03 lol
nitrogenycs 10:03 taxilian: hey, just read your mail
neilg_ 10:03 Do you happen to know whether the CALayer that is created in PluginWindowMacCA is a basic CALayer (my guess) or a CAOpenGLLayer? I'm going to get back on that today and I haven't looked yet.
If you don't know, don't worry - I'll go looking when I get to that point
taxilian 10:03 neilg_: pretty sure it's a CAOpenGLLayer
but I could be wrong
we're using opengl
but we might be making another CALayer inside the one the pluginwindow creates
neilg_ 10:03 If so then that's awesome. Less work for me! :)
taxilian 10:03 nitrogenycs: so, thoughts?
neilg_ 10:03 Thanks
taxilian 10:03 hmm. maybe it doesn't create another layer
I was thinking it did
I guess it just gives you what the browser gives you
so you'll have to mkae your own CAOpenGLLayer
my bad
stuartmorgan 10:03 taxilian: the browser doesn't prove a layer
taxilian: the plugin does
neilg_ 10:03 I didn't think the browser... Yes, what stuart said
If FB creates a basic CALayer that's still fine, I can attach my own CAOpenGLLAyer to it.
taxilian 10:03 FB does not create a CALayer, looks like
nitrogenycs 10:03 taxilian: wrote a reply mail. feel free to talk about this here with me, then we can spare us some lengthy mails :)
I hate that gmail doesn't send list email back to me
stuartmorgan 10:03 taxilian: uh, that code makes no sense at all
taxilian 10:03 nitrogenycs: actually I haven't gotten it either
stuartmorgan: it seems to work. explain?
stuartmorgan 10:03 NPWindow->window is always NULL
johnd_ 10:03 This is not a FB-specific thing, but I notice my FB-GL test flickers terribly when scrolling the main browser window. I have seen other plugins do this too, is it a side-effect of how plugins work?
nitrogenycs 10:03 taxilian: maybe gmail takes a while, I'll just copy it to pastebin for performance :)
taxilian: he it is:
taxilian 10:03 johnd_: I've seen this happen as well, particularly on windows; I don't know of a way to fix it, though you can minimize somewhat the flicker by handling the RefreshEvent and forcing a draw whenever that happens
nitrogenycs: just came through finally :-P
stuartmorgan 10:03 taxilian: see also
johnd_ 10:03 That's what I do... on RefreshEvent I invalidateRect which triggers WM_PAINT. I wondered if it was related to the windowless/windowed decision? Unity does the same but Flash doesn't
stuartmorgan 10:03 No browser is ever going to call NPP_SetWindow with a CALayer in the NPWindow struct
nitrogenycs 10:03 taxilian: people can alter the reserved names in their JSAPI classes derived from JSAPIAuto, that's just what I did for fixing my current problem
taxilian 10:03 stuartmorgan: it is possible there is more going on in the NpapiPluginMac class; let me see
hang on
yeah, he puts it there
I believe to make things more consistent
nitrogenycs 10:03 taxilian: just place some setReserved("attributes"); into the constructor. The idea is to be able to do something like setReserved( getDefaultReservedAttributes() ) or clearReserved() or just being able to access the m_reserved member directly
stuartmorgan 10:03 Ew
FYI, that code leaks the layer
taxilian 10:03 stuartmorgan: I can see your point, though I also see his; I will consider it.
stuartmorgan: where?
stuartmorgan 10:03 It's retained twice
Where it's created, in GetValue
taxilian 10:03 generally any time you return something from GetValue you need to retain it before you return
NPAPI standard is that there is always an implicit retain when returning something from GetValue (or anywhere else, really)
neilg_ 10:03 Ah, line 153
taxilian 11:03 so why would you not do a retain before giving it to the browser there?
stuartmorgan 11:03 taxilian: See "CALayer lifecycle" in the link I pasted above
taxilian 11:03 interesting
okay; that's weird
but okay
stuartmorgan 11:03 Not in Cocoa terms
taxilian 11:03 I'll pass it in and let him know
pass it on*
stuartmorgan 11:03 And it's a Cocoa object
taxilian 11:03 well, I personally don't know Cocoa =] I just know NPAPI
I'll ask Eric about it, though
for now it's not a major leak
but does need to be fixed
wait… there are two places where it calls release as well
actually three, technically
so I'm not sure there is a leak
I'll run through it with Eric
not sure why he's retaining it in GetValue
stuartmorgan 11:03 taxilian: I see a retain/release pair in this class, another pair inside the window class, and the dangling retain
taxilian: imagine the browser calls GetValue 10 times and it's clearer that it's a leak ;)
taxilian 11:03 yeah, I was seeing that
like I said, I'll ask him and we'll take care of it =] if you have a chance and could glance through the other pluginwindow classes I'd appreciate other feedback
I'm not concerned enough about passing the calayer in through the NPWindow to be worth arguing about it with him, so let's just let that one slide for now
looks like we need to add the invalidate for InvalidatingCoreAnimation as well
stuartmorgan 11:03 It would be easier to read these if there were a space/tab standard ;)
taxilian 11:03 I can fix that real quick if you'd like
there comes a point when I'm willing to put up with minor inconveniences to have someone who knows the mac stuff really well doing it
amackera 11:03 what is our space/tab policy?
taxilian 11:03 4 spaces
and I have a script (/fixtabs) that I run periodically to fix it when people forget
because I'm not going to reject patches and fixes just because they don't have the right spacing
FB_GitHubBot 11:03 FireBreath: master Richard Bateman * ca505a6 (45 files in 10 dirs): Converted tabs to spaces -
taxilian 11:03 hmm
no wonder it didn't wokr
wasn't catching .mm files :-P
nitrogenycs 11:03 kudos to everybody who doesn't reject patches because of silly little minor issues :)
it gets annoying when people get anal about every single character in a patch
taxilian 11:03 yeah; I am really picky about certain things, but if I can fix it with a shell script I don't care =]
FB_GitHubBot 11:03 FireBreath: master Richard Bateman * 5999216 (5 files in 3 dirs): Fixed .mm file tabs -
taxilian 11:03 stuartmorgan: that should help
tony_ 11:03 Which is the best and stable version for mac plugin..I wnat to use Coregraphics
nitrogenycs 11:03 tony_: did calling navigator.plugins.refresh work?
tony_ 11:03 yes yes !! it worked like a charm !
thats alot man :)
stuartmorgan 11:03 taxilian_away: thanks. I'm confused by the negotiation in PluginWindowMac since it doesn't have any event stuff. Didn't there used to be a big combined negotiation system?
nitrogenycs 11:03 :) ok cool
stuartmorgan 11:03 And that correctly handled things that didn't negotiate, which this doesn't seem to?
It also doesn't look like PluginWindowMacCG::SetWindow works for Cocoa, where window->window is NULL, unless there's yet more magic fixup happening somewhere
Although how that fixup would work I can't imagine since SetWindow will be called before the paint event provides a context
Oh... you changed to a one-to-one binding between drawing and event models
And don't allow CG+Cocoa
That's going to be a serious problem when Firefox 4 ships
This comment is totally wrong, by the way:
(and the one after it doesn't make sense, given that Safari doesn't support invalidating CA and probably never will)
amackera 11:03 stuartmorgan: why not support CG+Cocoa?
stuartmorgan 11:03 amackera: I'm saying FB doesn't
Which is a terrible, terrible idea
amackera 11:03 I see, yes
stuartmorgan 11:03 Last time I saw the negotiation code it was totally different, and did allow that comdo
But this refactoring is totally broken
amackera 11:03 hmm
stuartmorgan 11:03 As it stands now it's impossible for anyone to use CG with a 64-bit browser in FB
Well, I guess CG+Carbon works in Safari 64-bit, so it's just Firefox that will be broken
And anyone trying to make 64-bit plugins
taxilian 11:03 why is that?
stuartmorgan 11:03 Because Carbon isn't valid there
taxilian 11:03 right… what does that have to do with CG?
stuartmorgan 11:03 taxilian: see the link and all my comments above
taxilian 11:03 oh, sorry, I didn't see that
I will read it now =]
stuartmorgan 11:03 Between ICA not invalidating, and CG now forcing Carbon, I don't think it's possible to make a FB plugin that will work in Firefox 4 64-bit
taxilian 11:03 I'm not sure where that comment came from; I didn't write it
sorry, I'm trying to skim in 2 minutes what you've look through already
does it actually restrict using Cocoa w/ CG?
it shouldn't...
hmm. interesting
stuartmorgan: do you have time that you could fix it for us?
stuartmorgan 11:03 No, especially since the whole structure here doesn't really make sense to me.
The negotiation needs to be completely restructured to look like it looked before; no clue how you want to make your factories work
And your CG window class needs potentially serious work
Because it's based on the idea that you get a context in SetWindow
And you don't in Cocoa
You only have a context *during* a draw call, and you shouldn't cache it between calls
taxilian 11:03 could you explain what the problem with the new structure is?
stuartmorgan 11:03 So enabling CG+Cocoa without rewriting your CG code would still not work
taxilian 11:03 I don't see how that would be impossible to make work with this structure
CG is the one piece that Eric isn't using at all, so it's not surprising that it is the weakest point at the moment
there is no reason we should need two different objects for CG though
and that was the main thing he was trying to fix with his restructure
stuartmorgan 11:03 The new negotiation structure is wrong because it is based on the idea that event and drawing negotiation are orthogonal
They are not
Not all models combinations are valid
I guess you could probably keep something like this if you don't care about letting FB users shoot themselves in the foot by not having the right #define combos
taxilian 11:03 I understand that; however, it should be possible to negotiate in such a way that we still use a combination event class and drawing model class
I'm not saying I'm not willing to keep any of it; maybe I'm misunderstanding you
if we can change the negotiation in such a way that it still works with the same classes that we have in 1.5, I'm good with that
I have no problem at all with SetWindow changing or even not getting used on certain models
stuartmorgan 11:03 taxilian: the API of PluginWindowMacCG doesn't make sense though
taxilian 11:03 fair enough; how do we fix it?
stuartmorgan 11:03 I don't know what your drawing abstraction is supposed to be
taxilian 11:03 we don't currently have a drawing abstraction
we have an abstraction for getting you what you need to know so that you can draw
stuartmorgan 11:03 I mean your architecture abstraction
getDrawingPrimitive is fundamentally broken for CG+Cocoa
The drawing primitive is not a property of the window
It's a transient property of a draw event
taxilian 11:03 right
so the way that works on windows is when it comes through it sets the context on the window
and we fire a draw event
during the draw event you can call a method on the window to get the context
after the draw event that context and method are no longer valid
I was thinking we would do it the same on mac, essentially
does that make sense?
stuartmorgan 12:03 I guess if it works on Windows it should work on the Mac. That seems like a really dangerous API, but maybe I just don't know enough about your design
taxilian 12:03 could you explain your concern?
stuartmorgan 12:03 An API should be hard to use wrong; something that returns a graphics context that's only valid in certain cases seems easy to use wrong. Ideally the graphics context, for this model at least, would be a param of whatever your draw call is
So that nobody could think "hey, I need to draw in this callback... I'll just call getDrawingPrimitive and use that!"
(where "this callback" is some random timer, or something else that's not a draw event)
taxilian 12:03 I can accept that
how about this?
we extend RefreshEvent and create CGDrawEvent
it contains the context, which is only valid for the duration of hte event
we could optionally (for those who want to live dangerously) still have a getCGContext method that if you call at the wrong time throws an exception
stuartmorgan 12:03 I don't know anything about that part of your code, so I'm not a good person to ask about specific implementation of that approach
taxilian 12:03 I'm more wondering if you think that, conceptually, that would be a better implementation
bryan-_ 12:03 if I clone firebreath-1.4 from the git repository will that get the 1.4.1 version?
taxilian 12:03 the problem is that while I know the FireBreath codebase very well, I know almost nothing about drawing on Mac, so I would be a very bad candidate to fix this; amackera, are you able to look at it any time soon?
bryan-_: yes
bryan-_ 12:03 ok, thanks.
stuartmorgan 12:03 taxilian: if RefreshEvent is a parameter to whatever your abstraction of NPCocoaEventDrawRect/updateEvt, then yes, that sounds better
taxilian 12:03 okay, I see where your confusion is; these pluginwindow classes fire events to the plugin. The RefreshEvent is the one that says "the browser says you need to redraw"
stuartmorgan: I guess you're probably too busy to help with any of the coding on this yourself?
stuartmorgan 12:03 Yes
taxilian 12:03 fair enough; I appreciate your advice. so does FireFox 4 only support ICA?
not CA?
stuartmorgan 12:03 I believe they settled on just supporting it, although I'm not 100% sure; the original plan was to only whitelist one or two existing plugins for CA
To ensure that new plugins support ICA
That's also what Chromium was going to do, but that hasn't happened, and may not at this point, in favor of just evangelizing plugin vendors
taxilian 12:03 okay; I know Eric ran into some issues trying to support CA on FF4; I can't remember what they were right now. I appreciate your help; I'll leave you alone for awhile now =]
good toknow
dan2 12:03 what's the best way to return a list of strings from the plugin?
can I pass back a std::vector<std::string> ?
taxilian 12:03 no, but you can pass back a std::vector<FB::variant> which contains strings
that's what a FB::VariantList is, btw, if you want a shorter typedef
dan2 12:03 k
taxilian, what's the best way to pass back a structure of data with a string?
variantlist would be fine
since I need it sorted a certain way
taxilian 12:03 I considered accepting STL containers of arbitrary types as return values, but I'd just end up having to convert it to a variantlist anyway
it seemed like a better idea to leave that in the hands of the developer
dan2 12:03 ok, what specifically do I have to do to override convert_cast?
for a custom structure
taxilian 12:03 you are ambitious
should be doable, though
the main thing is that it has to be defined before you include variant.h
dan2 12:03 and it probably needs to be in FB namespace right?
taxilian 12:03 look in JSObject.h for an example
specifically, FB::variant_detail::conversion, I believe
dan2 12:03 k
taxilian 12:03 there are two conversion functions you can provide
make_variant which converts a type to a variant
and convert_variant which converts a variant to a type
you should be able to just forward-declare them before including variant.h and have it work
keep in mind that if what is in the variant isn't something FireBreath understands it won't get sent to the browser
dan2 12:03 k
taxilian 12:03 which is why make_variant could be useful
and let me know how it goes; nobody else has tried it yet
dan2 12:03 taxilian, do you already support lists of maps?
taxilian 12:03 you can put a VariantMap inside a variant
so yes
make your VariantMap and put it in a VariantList
keep in mind that every time you return that to the browser it has to call into JS to create the object, populate it, etc, so there is a minor performance hit; not usually enough to matter, but just FYI
dan2 12:03 taxilian, so, where do I override convert_cast
it's not in JSObject.h
taxilian 12:03 convert_variant is called by convert_cast
make_variant is called by assign and the constructor
taxilian 13:03 stuartmorgan: dont' know how much you know about FF4's ICA implementation, but we're having an issue where FF4 doesn't size the CALayer; any thoughts?
stuartmorgan 13:03 I haven't looked at their layer managemnt
I'd be surprised if they did anything different between CA and ICA in that respect though
taxilian 13:03 they dont' seem to
we just can't draw because the CALayer is always 0x0
just hoped you might have some idea :-/
stuartmorgan 13:03 taxilian: it may just be a bug
You could always size the layer on your side in the mean time. Definitely file it though, since they might be able to fix it for 4 still; not sure how close to release they are
taxilian 13:03 stuartmorgan: likely. so webkit samples specifically says that you should retain the CALayer in GetValue
stuartmorgan 13:03 Oh, those are old then
Once upon a time there was confusion about ownership
Then the spec was clarified
taxilian 13:03 how certain of that are you? (not to doubt you, just whenever there is conflicting info I worry)
also, are there versions of webkit that expect a retain to be done?
stuartmorgan 13:03 I doubt it; it was clarified over a year ago
In the thread about accepting the spec
taxilian 13:03 do you have a link for that?
that thread?
stuartmorgan 13:03 No, it predates plugin-futures having an open archive
But the Mozilla wiki is the authoritative spec
And here's the change where Simon Fraser, of Apple, changed the example from the old code to the correct code:
taxilian 13:03 fair enough; thanks
stuartmorgan 13:03 Note that the examples are the same if the browser calls GetValue only once
taxilian 13:03 sorry for being paranoid, just trying to make sure I understand what is going on. Thank you
Eric is still not convinced =] says the sample is dated very recently. I'll let him dig into it.
stuartmorgan 13:03 Eric should file a WebKit bug about their sample being wrong then. Again, the change I linked to above was made by an *Apple WebKit engineer*
If agreement among every browser implementing CA isn't sufficiently convincing, I'm not sure what would be enough evidence
taxilian 13:03 I will suggest that to him =] please don't take offense; I dont' know exactly what your connection to webkit, etc is, but I've never known your information to be inaccurate
his main concern is not what is currently there, I thin
but that there may be older versions of webkit that expect it to retain and will crash if it doesn't
taxilian 13:03 stuartmorgan: also looking at the CoreGraphics stuff; I may be missing something, but it looks like the context is passed into SetWindow when I read here:
is it different in 64 bit?
stuartmorgan 13:03 It's different in Cocoa
amackera 13:03 taxilian: that only happens in Carbon IIRC
stuartmorgan 13:03 The specs suck as docs for learning how this works, unfortunately
The problem is that the specs only really make sense when read chronologically
The CG spec predates the Cocoa spec, so doesn't refer to it
I've talked to Josh about this; he agrees there needs to be some overview doc or similar, it just hasn't happened yet
taxilian 13:03 yeah, it's very confusing. okay, so CG uses the SetWindow on Carbon, passes it in with the Draw event on Cocoa; should really be updated to clarify that
amackera 13:03 taxilian: discusses the changes due to Cocoa
taxilian 13:03 because it doesn't make any reference to this being a Carbon event
stuartmorgan 13:03 taxilian: re: the concern about old WebKits, that's possible. I don't know when Apple shipped CA relative to the spec being finalized, and what their implementation did. I just know how it *should* work ;)
taxilian 13:03 awesome… so the only way to know we're safe is to go back through webkit source history. you don't by chance know which version of Safari first supported CA?
stuartmorgan 13:03 taxilian: the CG spec isn't going to be changed in all likelihood. We might be able to put in a warning banner in that section mentioning to see the Cocoa spec though
taxilian 13:03 that would be good; or at least specify that it's only relevant to the Carbon event model, whcih really doesn't make sense since it refers to 64 bit mode in it
stuartmorgan 13:03 taxilian: I'm not sure the source history will help much; I'm not sure how easy it is to match their revision history to releases
I'd recommend just testing the latest version on 10.5 and 10.6, and not worrying about people who haven't updated
No idea when they started supporting CA, just that 10.5 was the first
taxilian 13:03 valid point, but while I can choose not to support really old vesions I'm not sure how recent I'm allowed to be; it's not my decision, unfortunately
stuartmorgan 13:03 (although not all plugin vendors find the 10.5 CA implementation satisfactory, so many treat it as 10.6+)
taxilian: you have to support unpatched versions of Safari?
taxilian 13:03 I have to support old versions of Safari
fortunately I don't think I have to worry about pre-10.5 you said was wrong; did you mean wrong just for 64 bit or wrong for 32 bit?
stuartmorgan 13:03 CA doesn't exist pre-10.5
taxilian 13:03 we used quickdraw
stuartmorgan 13:03 Right, but this is about how their CA implementation works
They don't have one prior to 10.5
taxilian 13:03 true. so we need to add a check for 64 bit so that it allows Cocoa/CG on 64 bit and not on 32 bit
stuartmorgan 13:03 Wait, what?
We're having two different threads mixed up here
taxilian 13:03 yes, partially; I'm going back over our earlier conversation now that Eric is online and I can ask him about it
setting aside the CA issue for now because I'm trying to figure out if there are other disconnects while I still have communication wtih both of you
stuartmorgan 13:03 On the CG issue:
The comment is totally bogus
taxilian 13:03 how so?
amackera 13:03 CG is both Carbon & Cocoa
stuartmorgan 13:03 It's bogus because Safari doesn't have any special combination requirements
Safari requires that the combination be valid
Meaning: CA+Cocoa, CG+either, QD+Carbon
As with all browsers
The only extra restriction is that they don't support QD at all in OOP mode
taxilian 13:03 on 32 bit safari?
stuartmorgan 13:03 (which they turn on in 64-bit)
But that's not a combination restriction, it's a drawing model restriction
taxilian 13:03 stuartmorgan: have you actually tested that? because our tests show that when you try to enable Cocoa and CoreGraphics in 32 bit safari it shuts you down; Eric says maybe it was late at night and something else was going on
stuartmorgan 13:03 There is no possible way that's true.
QuickTime uses that model in some cases
And in some versions of Safari, so does Flash
taxilian 13:03 ok; well, amackera: when you look at it, could you test that and verify?
stuartmorgan 13:03 Well, I guess it is theoretically possible that those plugins negotiate something else in Flash...
Oh, but I've loaded my test plugin in Safari
taxilian 13:03 I think we've hashed this out as much as it can be; at this point we'll just have to try it and make sure
then enable those combinations according to what we find
stuartmorgan 13:03 To see how Safari handles Cocoa in process and out of process
So yes, I have tried it. In both 32-bit and 64-bit Safari
taxilian 13:03 we really just need to make a full abstraction so that you don't have to worry about this mess
well, I'm going to go get some lunch. bbl
taxilian 15:03 dan2: did you get it working?
dan2 15:03 ya, this works great
taxilian, other than the fact that xul has some of the hardest to read documentation because it has you searching all over the place...
it works like a charm
taxilian 15:03 awesome
I tried to write it so you could do that, but since nobody has tried it until now… =]
nitrogenycs 15:03 taxilian: any comment about my idea regarding the reserved names?
taxilian 15:03 I can't decide if we should document that on the wiki or not; it's a really useful thing to be able to do, but misused it could be problematic
nitrogenycs: sorry, I've been pretty busy today; let me read it again
nitrogenycs 15:03 taxilian: no problem, I've seen your involved discussion about drawing on the mac
taxilian 15:03 yeah, that distracted me a bit =]
could you clarify what you mean with the GetProperty('tagName') etc to check for reserved properties?
nitrogenycs 15:03 there's this code in the fb npapi stuff where it gets the pointer to the npapi object of the dom element
when I did npnfuncs.getProperty('tagName') on this object, I was able to retrieve the name
i.e. it returned "OBJECT" for the object tag
taxilian 15:03 … it didn't direct it to ours first?
nitrogenycs 15:03 yes
I think ours isn't installed at that point
it gets installed later somewhere, but I didn't figure out where
taxilian 15:03 yes it is
I think
when we first create the browserhost it isn't, I suppose
nitrogenycs 15:03 So if we can enumerate the keys in that object, we know which ones are "reserved"
taxilian 15:03 so you're saying if you do it later it doesn't work?
nitrogenycs 15:03 if I do it later I always end up in the GetProperty supplied by ourselves
taxilian 15:03 okay
nitrogenycs 15:03 and from there I have no idea how to get at the original value anymore
taxilian 15:03 so I guess there are a couple of ways we could try this
depending on how exotic you want to be =]
nitrogenycs 15:03 there's something like InvokeDefault for methods, but I don't think there's something like GetDefault for properties
taxilian 15:03 no there isn't
you could set a flag that when set makes HasProperty always return false
nitrogenycs 15:03 to be exact, I put my code after
GetValue(NPNVPluginElementNPObject, (void**)&element);
taxilian 15:03 set it, call HasProperty(pName), then clear it
that way any calls which come in while the flag is set return false for hasproperty which will cause them to be handled by the DOM element
then after you clear it future calls will work normally
the whole thing would probably work because everything is serialized — it's all one thread
that would remove the additional overhead of doing an enumerate to start out with
and put the whole thing somewhere where we could use it with the JSAPI object
since there is currently no actual connection between the JSAPI object and the BrowserHost
nitrogenycs 15:03 hmmm, I am not sure I get this yet. When does this flag get set and who does it?
taxilian 15:03 okay, so you'd do it like this:
in NPJavascriptObject, HasProperty comes in
hmm. no, because we don't know about our DOM element there either
nevermind, that's no better
nitrogenycs 15:03 from my little understanding and the experimentation it seems NPJavascriptObject is too late
taxilian 15:03 well, you can make it not too late
nitrogenycs 15:03 but I am not sure since I don't have the high level picture of the npapi js things yet
taxilian 15:03 by simply setting a flag before we check the property
then when the call recurses back to us, we see the flag and say "oh, we're doing a property check, return false"
which prevents the infinite recursion
nitrogenycs 15:03 ahh ok
taxilian 15:03 the problem is that NPJavascriptObject doesn't know that it is the root JSAPI object
nitrogenycs 15:03 yes
taxilian 15:03 so we may need to have some way to tell the JSAPI object if it is a root object or not
if not, none of this needs to be done
nitrogenycs 15:03 yeah
taxilian 15:03 brb
nitrogenycs 15:03 this is still configurable right? You can set the flag based on the propertyName passed to HasProperty
I am not sure if the more explicit way through enumeration might be better. You can do the enumeration once and then cache it for the length of the entire run, since the dom won't change.
taxilian 15:03 true; I guess I just still try to avoid enumeration because it didn't work on ff 2.x, but that's definitely so old that we don't care anymore
are you willing to do some tinkering for me? I don't have time to do this for at least a couple of weeks
but I have an idea if you want to try implementing it
I don't think it would be too hard
nitrogenycs 15:03 I don't have time right now either, but I will put it on my list
taxilian 15:03 ok; well, I'll keep thinking about it
nitrogenycs 15:03 It's good to know it's possible one way or another
taxilian 15:03 it is; it will be tricky
nitrogenycs 15:03 yes
taxilian 15:03 I'm thinking that we'll want to add a setDOMObject method to JSAPI that gets called by PluginCore right after the JSAPI object is created
before it is attached as the main object
and when it is called, the JSAPI object will enumerate members and set them all as reserved
nitrogenycs 15:03 yeah, something like this
taxilian 15:03 replied to your email
please add an issue for this; then if you find time to work on it comment on the issue so we know someone started, and I'll do the same
we'll see which of us gets to it first
nitrogenycs 15:03 ok, cool, read it
thanks for help :)
taxilian 15:03 thank you
nitrogenycs 15:03 issue #164 created
taxilian 15:03 awesome
nitrogenycs 15:03 I will keep it in my list of things I need to get at, but right now I have other problems to solve first
taxilian 15:03 I understand completely
I do too =]
like this one:
it'll be a little trickier
nitrogenycs 15:03 do you have a special use case for this in mind? like string arrays?
taxilian 15:03 yeah; I have a video player that fires event into the DOM at least 4x per second and sometimes sends mousemove events which are even faster
it's too slow currently =]
also currently if you fire an event that uses an array or map from a secondary thread it will have to make n+1 cross-thread calls, where n is the number of items inside the object
that's not real efficient
you can solve that simply by using ScheduleOnMainThread to call the FireEvent method
but I'd prefer to have that automatic
nitrogenycs 15:03 ahh ok
I haven't yet needed events this fast
taxilian 15:03 most don't
a few have
there are probably a lot of places FireBreath could be optimized
I just don't see any reason to spend a lot of time on it until I find sepcific instances where the current performance is an improvement
nitrogenycs 15:03 I am pretty sure I will need events faster than 4x a second quite soon, but first need to work out a few more details in my world domination plan :)
taxilian 15:03 fair enough =]
nitrogenycs 16:03 can this ssl host thing you did ensure that only my own javascript will be executed with the plugin?
is there a wiki page where I can read up on it
taxilian 16:03 hmm. not sure I understand your question
and no
there are no docs =]
you talking about the embedded webserver?
nitrogenycs 16:03 I think that was it
Basically my current way of doing things is starting a python program to which I can talk with events from javascript back and forth
this python program is a signed and verified .exe file
so it's all nice
now people can run arbitrary javascript code against it and it should be secure
taxilian 16:03 what you can do that way is make it so certain APIs can only be used when running on a page hosted at localhost
nitrogenycs 16:03 I'd like to run arbitrary javascript against my c++ libraries as long as it's my javascript :)
hmm, I guess I could sign it, too and then run it on localhost if the verifications succeeds
i'll think about it more, then ask refined questions :)
taxilian 16:03 you could pull a google and embed V8
taxilian 16:03 nitrogenycs: there might be a way to tell where certain javascript came from, but if so I don't know what it is; all you can do is only enable certain APIs to be accessed from a location that you trust
and open that in an iframe
nitrogenycs 17:03 taxilian: Yes, I could embed google's V8, but then I can't use the browser for html rendering
taxilian 17:03 why not?
set it up so that you can pass JSObjects into V8
create a wrapper for JSAPI
then you can access the browser DOM from V8
actually, I think that'd be a cool project to make into a FireBreath library so it'd be easy to reuse
nitrogenycs 17:03 yes, but I am more interested in going the opposite way, reading values into the browser's javascript for display
taxilian 17:03 your interest seems to be primarily in having trusted javascript to control the page
nitrogenycs 17:03 for a V8 and/or firebreath language binding bridge I am in contact with somebody else from the swig mailing list
taxilian 17:03 you could do that with V8; just pass DOM elements and/or page javscript functions in and call them / manipulate them from V8
nitrogenycs 17:03 He already has a simple prototype to wrap C++ to V8 I think
taxilian 17:03 I suspect going through SWIG would be overkill, but I may be wrong
nitrogenycs 17:03 swig just generates the code
taxilian 17:03 ahh
nitrogenycs 17:03 i.e. SWIG can output a JSAPIAuto class
which is automatically generated for a c++ api
taxilian 17:03 well, remember that FireBreath already provides two different interfaces for dealing with javascript; adding a third would be pretty easy, I suspect
nitrogenycs 17:03 i.e. it would create those register_method calls and such
while taking care of inheritance and such things
taxilian 17:03 fair enough; I'd be interested in seeing it when you get it going
I might have some suggestions =]
nitrogenycs 17:03 yes, I am currently not sure if I am going to invest into it or not. I'm finishing the up-front work now and then choose from one of the ways that are open
taxilian 17:03 fair enough. give some thought to just making a JSAPI<->V8 bridge, though
it would make using V8 with FireBreath very easy
nitrogenycs 17:03 I am not sure if the "just pass DOM elements and/or page javscript functions in and call them / manipulate them from V8" part will work as expected
taxilian 17:03 well, the cross-threadness would be a little tricky
nitrogenycs 17:03 I can't pass a dom element from e.g. opera's browser engine to v8
taxilian 17:03 but I don't know of any other reason it would be an issue
ahh, but you can if it's wrapped inside a JSObject
because the JSObject knows where it came from
I have actually done it with two different javascript engines
they were actually full web browsers, but the same concept applies
all V8 would know is that it had a Javascript Object (of whatever type it uses); that type would only now that it had a JSAPI object
nitrogenycs 17:03 so you say I can do something like document.createElement('div') in opera, take the JSObject from this (e.g. through firebreath) and then input that to V8?
taxilian 17:03 pretty much, yeah
it's a tiny bit more involved
but yes
nitrogenycs 17:03 hmm
how is this possible? was the V8 api specifically crafted for this?
taxilian 17:03 no
FireBreath was
I am making the assumption that it is possible to create C++ objects that interact wtih V8
but I think that's a safe assumption
nitrogenycs 17:03 I guess I need to take an in-depth look at the v8 api
taxilian 17:03 think about it; what is a NPObject in Chrome?
it's a C++ object that javascript can call methods and properties on, right? and it uses V8?
nitrogenycs 17:03 hm
this would certainly open interesting opportunities
taxilian 17:03 when you do new Date() in javascript, it creates an object that is likely implemented somehow in C++
all you then need to do is write a V8 javascript object (however you do that) that wraps a JSAPI object
and suddenly anything you can put in a JSAPI object can be used in V8
you could even fire events into your internal javascript
it's the same as how we integrate with the browsers right now
to do events you'd need to make a BrowserHost object for it that knows how to make async calls to the V8 thread
actually either way you'll need to, I suspect
but anyway
it's possible
nitrogenycs 17:03 yes, the threading is a small problem, but could be solved
the idea is nice
taxilian 17:03 if you're willing to open source part of the results I'll even help you with it
nitrogenycs 17:03 I think I might have a 3rd contributor for this
taxilian 17:03 also nice =]
nitrogenycs 17:03 yes, open sourcing it is fine
taxilian 17:03 the other nice thing is that if you have that JSAPI wrapper then you can create other object types using JSAPIAuto that will work in V8
brb, gotta go to class
nitrogenycs 17:03 okay, I'll think more about this
have fun in class :)
jshanab_wcw 17:03 my plugin has quit working in IE,chrome, and safari, but works in FF. it is "unresponsive in chromw and just plain locks up IE and safari. Does this indicate anything in particular?
taxilian 17:03 jshanab_wcw: yes, it means that something is wrong
I recommend you fix it
jshanab_wcw 17:03 It comes up in chrome after 3-5 min of unresponsiveness and not using any cpu. profiling says it is in ntdll.dll and it runs the begin com map 5 or 6 times
taxilian 17:03 have you tried attaching a debugger?
jshanab_wcw 17:03 yeah, it just keeps going off into ntdll.dll on the com declartion line and hangs.
taxilian 17:03 even on chrome?
what version of vs are you using?
jshanab_wcw 17:03 I think i have an idea for the mornings debugging session, dinner calls. Chrome eventually came back. I think i have a thread race condition
taxilian 17:03 you can load the symbols for ntdll, then
not hard
that may help you see what is happening?
nitrogencys: feel free to get V8 building with FireBreath and push it to github somewhere and I'll play with it as well
oh, you weren't here :-P
nitrogencys: feel free to get V8 building with FireBreath and push it to github somewhere and I'll play with it as well
btw, Facebook has chosen to renew my contract for another 6 months
which means that I'll be working on at least firebreath related stuff for the next 6 months
nitrogenycs 17:03 taxilian: :) cool
taxilian: congrats and great news
taxilian 17:03 =]
nitrogenycs 17:03 taxilian: I'm currently writing to the swig guy
maybe I can get him in here and we can have a short chat in the next days
taxilian 17:03 sounds good to me
nitrogenycs 17:03 I understand your idea now
taxilian 17:03 =]
I think it'd be cool to do the same thing wtih python; make a python object wrapper for JSAPI
nitrogenycs 17:03 I guess this means we could run V8 in IE for some speed boost :)
taxilian 17:03 so you could have a python vm running
nitrogenycs 17:03 I could do this with my current code already
but it's not of much use
taxilian 17:03 ahh, but it would be cool ;-)
nitrogenycs 17:03 If I access my C++ stuff through python from javascript it's slow
If I access c++ through javascript from python it's slow, too. Plus I already have a direct python -> c++ connection
taxilian 17:03 that's not the point; the point is that you could create c++ objects that would work with python using JSAPI
nitrogenycs 17:03 of course being able to manipulate the dom from pure pyhton is also an interesting idea
I know
taxilian 17:03 and access JSAPI objects from either python or javascript and have it be the same API
nitrogenycs 17:03 yeah, you could call python function from javascript or javascript functions from python
taxilian 17:03 yes, but you're still missing what I'm saying
most JSAPI objects are neither javascript nor python objects
they are C++ objects written to provide an API to the page
but if you wrote an adapter layer they could be accessed from python as well
so it could be used to let javascript call python calls, python call javascript calls, or from either to call the JSAPI calls that you provide
nitrogenycs 17:03 Making the objects simply accessible is not of so much use. It gets much harder to e.g. map the different class concepts and inheritance things to each other
taxilian 17:03 well, it isn't of much use to you
nitrogenycs 17:03 e.g. how do you wrap c++ classes and multiple inheritance to the javascript objects and then back to the python objects
taxilian 17:03 because you do your plugin logic in a scripting language
but if you were providing an API to, for example, a video player that lived in the plugin
then it is of great use because it allows you to easily provide an API to that video player to both languages
nitrogenycs 17:03 yes, but the api for a video player is super simple and has no complex classes and such
taxilian 17:03 LOL
depends on the video player
nitrogenycs 17:03 :) the video players I am used too at least
taxilian 17:03 yeah; the one I'm working on is a lot less simple
because it supports multiple streams concurrently, it's adaptive bitrate and supports configuration of hte profiles, etc
there is a lot more than you'd think
nitrogenycs 17:03 yes, but you could have a plain C api for that
taxilian 17:03 yes; and they used to
nitrogenycs 17:03 which makes the api itself simple, even if there are many functions
taxilian 17:03 it made it really a pain in the neck to use from javascript
nitrogenycs 17:03 my library's api is way more complex. E.g. there are c++ classes you can inherit from on the python side (cross-language polymoprhism). E.g. I can create an abstract class in C++ and then write the implementation in python.
taxilian 17:03 yeah, you can't do that with JSAPI
and I don't see a way of doing so
however, you could use encapsulation and forwarding instead of using direct inheritance
nitrogenycs 17:03 yes, figuring out automatic mappings for things like this is something we need to do for the swig v8 bindings
if you go the c++ -> python direct wway you don't have those problems as the concepts match better 1-to-1
e.g. python has multiple inheritance and other oo things
taxilian 17:03 true; the more languages involved the more abstract it has to be
nitrogenycs 17:03 if i'd put a jsapi thing between, I'd lose the tight C++ -> python mapping style
taxilian 17:03 anyway, I'm not saying it would match your use case well
just that it would be cool to be able to make a JSAPI API and have it work everywhere; python, JS, whatever
nitrogenycs 17:03 yes, but it's a nice idea in general and I agree many people will find it useful
JS as the lingua franca :)
taxilian 18:03 heh
nitrogenycs 18:03 ok, mail sent to the swig guy. I'll keep you posted.
taxilian 18:03 cool