IRC Log Viewer » #firebreath » 2010-10-25

IRC Nick Time (GMT-7) Message
taxilian 07:10 nirvdrum: sorry about the build break in dev over the weekend
nirvdrum 07:10 No problem. I just thought the RC was broken.
I was worried more for your sake than mine :-)
taxilian 07:10 hehe. yeah, that's always embarrasing
this RC has changed much more than I expected it to
kalev 07:10 when are you planning to do the release?
I saw a crash in my plugin, but I won't have time to debug it today. No idea yet if the crash is in Firebreath or my code.
taxilian 07:10 was hoping to do it Thursday
kalev 07:10 good, then I have plenty of time to figure out the crash
taxilian 07:10 the last release (1.2) we knew we'd need a 1.2.1 within 24 hours of releasing; I'm hoping to avoid that this time =]
releases are actually a fair amount of work for me, despite having the build process automated =]
kalev 07:10 yeah, lets hope for a solid release
taxilian 07:10 I'd prefer to have everyone test it with the RC and then we don't just have to hope.. we know =]
nirvdrum 07:10 Then fix -dev dammit :-P
kalev 07:10 you can count on me here, I'll make sure everything works fine with my plugin
taxilian 07:10 nirvdrum: I think cygmatic already mostly fixed it
and to really fix it will need amackera, I think
nirvdrum 07:10 I'm just kidding.
taxilian 07:10 but I think it should build and work now
nirvdrum 07:10 Getting the JSObjectPtr fix in would be swell though.
taxilian 07:10 which one? for downcasting?
nirvdrum 07:10 For freeing up on the appropriate thread.
taxilian 07:10 the thread one
yeah, that'll be in 1.3
it just slipped my mind
nirvdrum 07:10 No worries. I should have filed the ticket two weeks ago.
taxilian 07:10 always create an issue, even if I tell you I'm on it ;-) I have the memory of an 80 year old sometimes
kalev 07:10 did I already mention today that I don't like the way merges between -dev and main repo are happening? :)
nirvdrum 07:10 You just underestimate how much I loathe gcode's issue tracker.
kalev 07:10 it's just so complex that I don't understand what's really happening, and every time such a merge happens I'm holding my breath that some patch didn't get dropped
taxilian 07:10 kalev: I know it's not always pretty, but the stage during which that occurs is usually very small
and I'm handling those merges personally to prevent that
registering for my last semester of classes at the university
and naturally, two of the classes I need occur at the same time
kalev 07:10 anything interesting coming up?
cygmatic 07:10 kavel, any better ideas for the merges? :)
taxilian 07:10 compilers should be interesting
operating systems should be interesting
we built a VM this semester; next semester I'll write a compiler that compiles to the VM and an operating system that is built on the VM
cygmatic: it's kalev, not kavel LOL
cygmatic 07:10 argh, not again
taxilian 07:10 ;-)
cygmatic 07:10 well, i'm heading for OSX 10.5 - for the xth time today
kalev 07:10 cagmytic: ideally we wouldn't need merges at all: all development happens in the main repo, and when it's release time, we branch off a release branch.
taxilian 07:10 well, I gotta head to class. this is just great; two of my 5 required classes for next semester overlap and two of them aren't in the system so I can't register (we're going to hope they just haven't put them in yet)
kalev: that's what we do; the release branch is trunk
unfortunately, sometimes after the branch we find something that really needs to go into the release branch
kalev 07:10 let me write up what's the difference between those two models
taxilian 07:10 such was the case this time
that is one reason I'd love to switch to git, though; it would let us make that split more cleanly
kalev 07:10 yes, I agree here, although it might cause pain for some people who have already gotten used to hg
taxilian 07:10 that's why I haven't done it (yet?)
also the issue tracker; that's the main reason that I'm considering setting up JRIA
if we break from google code for issue tracking, then it's easier to break from google code for the source control
'course, dunno if github provides a downloads area
kalev 07:10 no idea, but it's no longer a problem as you have your own site where you can also host downloads
taxilian 07:10 I do have the site, but bandwidth is not unlimited
and I pay for that server out of my own pocket
granted, it would likely take a fair amount of traffic to become a problem
but FireBreath has the potential to generate that
and that server is intended for commercial purposes; I am not the sole owner
what might make the most sense would be to host it on Rackspace cloud files
for downloads
because that can be set up in a CDN architecture, so downloads would be fast
but I'd be paying $.22/gigabyte, again out of my own pocket
nitrogenycs_ 07:10 can't you host only the download at google or sourceforge or sometihng?
taxilian 07:10 that's kinda what I'm thinking
even if I move the source control to git, I may leave downloads on google code
but again, I'm still not sure that I can justify moving source control to git; it'd throw off a lot of people and I'm not sure the benefits justifies the pain required
nitrogenycs_ 07:10 No idea, I already have too many sccs installed: svn, hg, git, bzr
no cvs, yay
taxilian 07:10 hehe
nitrogenycs_ 07:10 if you want to have gigabytes of bandwith at a decent quality you either have to pay or use one of the free sites
taxilian 07:10 right
nitrogenycs_ 07:10 I tried to find some good deals for our own site
the cheapest cdn I found was
neilg_ 07:10 Morning all!
nitrogenycs_ 07:10 maybe not cheapest, but cheapest of the ones where the reviews looked ok
taxilian 07:10 shaoden (the server hosting has 1MBps burstable bandwidth, which isn't bad
nitrogenycs_ 07:10 morning
taxilian 07:10 but I'm not sure it'll long be enough to handle firebreath downloads
neilg_: morning
nitrogenycs_ 07:10 I got a dedicated last week. I have 100MBps steady there
I can upgrade to 1GBps
and all bandwidth included
taxilian 08:10 nitrogenycs_: yeah; I've looked at some options like that. However, I think for straight downloads rackspace files would be cheaper since we'd only pay for the bandwidth used. However, that still would require money from my pocket, and that's not something I'm ready to do without a really good reason =]
neilg_ 08:10 This is a topic close to home, this is something my team have been looking at a lot for the past ~6+ months
taxilian 08:10 rackspace cloud hosting, btw, is probably the fastest VPS system I have used
though I finally just got a dedicated server with
nitrogenycs_ 08:10 taxilian: at you can also buy like 1TB of bandwidth once and then use it till its up
taxilian 08:10 anyway, I gotta head to school. be back online later, guys. test the latest nightly rc build =] I want to put out RC3 today, and I'd really like to not have a RC4 =]
nitrogenycs_ 08:10 bb
taxilian 08:10 cool
neilg_ 08:10 See ya
Anybody got insight into plugins within IE and strange behaviour?
I grab the window handle for the plugin instance and using that I draw to the window
But if I click outside of the plugin window then everything within the plugin window goes blank...
cygmatic 08:10 sorry about that, i got the first part about branching rcs out?
kalev 08:10 so, I tried to draw some ascii graphics with branching:
cygmatic 08:10 ascii art is always great
kalev 08:10 I pretty much failed to draw the current scheme, but I think the ascii art of what I am proposing looks pretty nice
my biggest gripe is that right now I can't just look at dev branch's history: almost every commit is doubled in there and it's cluttered with merges back and forth, really confusing
cygmatic 08:10 for me it looks good, would also like this to be a bit cleaner
kalev 08:10 for example, look at this page:
we have two different development lines hanging in the air (not merged with anything)
I just don't understand the history if it looks like that
cygmatic 08:10 oops, what happened there
that looks broken
and i don't get what happened there ^^
kalev 08:10 that's exactly what I'm thinking: I just plain don't understand what's going on
the history is full of things like that
cygmatic 08:10 taxilian_away, do you see any problems with kalevs proposal? i can't think of examples where it couldn't be done
alright, going home now... later
iaincollins 08:10 hello again
regarding the build process am much happier after a bit of tweaking of the cmake files (and a bit to the templates on my v1.2.2 base)
but would appreciate it if someone could confirm if this is also what they see (and any suggestions)
when installing on Windows and specifcally with MSIE; if I have a version of a plugin installed aready (via WiX) and loaded in the browser,
(which, if it sees it it out of date triggers a "download the latest version" message),
if a version has already been loaded in MSIE (even if it is not currently active on the page) then the browser does not see the latest version of the plugin until the browser is restarted
I am considering having it bump the mime type so that it has a revsion number that goes up in it (but this seems nasty) as registering new plugins without a restart being required is of course
*is of course fine
but wanted to check to see if anyone had any suggestions on WiX voodoo I should be observing
(the MSI package upgrade handling is all straightforward and fine; it's just the "MSIE not recognising new version of plugin until browser restarted" issue that I can't seem to find a resolution for)
neilg_ 08:10 I'm no WiX expert but I've dealt with installing plugins on Windows quite a lot. I'd say you're doing the right thing sadly.
What we do is detect whether any supported browser are running and bring up a message asking the user to close the browsers to continue. If they choose not to then they won't be using the plugin
iaincollins 08:10 cool, I was just reading up on CloseApplication now and it seems like that was the way to go
(CloseApplication directives for WiX that is)
neilg_ 08:10 Taxilian: If you're around I definitely have a weird situation that maybe you have some insight into?
iaincollins: Yup, that's more or less the path we went down. We haven't supported IE until now, just Firefox and Chrome - but it's the same behaviour there in any case
The browsers just load the plugin DLL and won't unload it until they are closed
iaincollins 08:10 thanks for confirming that's what you are doing (nice to have some confirmation I'm not doing something too bad and evil)
taxilian 08:10 neilg_: just got back, reading the history since I left
iaincollins: it is possible to update an MSIE activex control and have it detect without restarting
but if you don't have to, restarting the browser is less error prone
neilg_ 08:10 I wouldn't recommend trying to make it work with different MIME types though, it seems like that would take you down an undesirable path. :)
taxilian 08:10 kalev: I definitely like your proposal, but I'm not sure how to implement it with mercurial in the current system. I totally agree with you as to the mess in the branch history.
neilg_: yeah, it can be done (and I have done it), but you actually need both a different mime type and a different CLSID for each version, which is messy
kalev: The problem is that I have tried using mercurial "branches" and it is partially responsible for the mess the repository is in
iaincollins 08:10 taxilian: Oh, hmm I see. I did recall you suggesting somethign to that effect, so I thought I'd ask again (now I've updated the build process to have it build a DLL with a unique name in a WiX and in a position where it's easy for me to test it easily).
neilg_ Yes It does seem overly evil (great user experience... but....)
taxilian 09:10 iaincollins: If you remove the object tag from the DOM and add it back in, it should use the new one if you've done the registry stuff correctly
iaincollins 09:10 *nod* kk thanks
I'll mull that over as to what is the least annoying (I'm being picky about the user experience I know)
taxilian 09:10 iaincollins: but again, there are so many ways that can go wrong if something isn't quite right in the registry that if you don't have to do it, better not to
iaincollins 09:10 apprecaite all advice
taxilian 09:10 no problem
kalev 09:10 taxilian: yeah, I think the strategy I was proposing works best with branches, although I guess you could create a separate _repo_ for each of the 1.1, 1.2, 1.3 release management
iaincollins 09:10 hmm I'll take that advice strongly then I think
kalev 09:10 taxilian: anyway, I think it's something to seriously consider changing if/when you decide to switch to git.
taxilian 09:10 kalev: yeah, and that's the reason that I haven't tried to do it that strongly; if I create a seperate repo for each it'll get out of hand really really fast
and branches in mercurial so far seem to cause more trouble than they are worth
taxilian 09:10 nirvdrum: I have the change done, I think, just doing a preliminary test
I'll want you to test it in your multithreaded app before we put out the next RC, if that is okay
nirvdrum 09:10 Cool. I won't be able to check it out until this evening.
taxilian 09:10 ok; everyone, RC3 will be put out tomorrow morning. anyone have anything that needs to go in that hasn't yet?
neilg_ 09:10 taxilian: I'm having issues with the IE plugin (works in Firefox, Chrome and Opera) where the window for the plugin instance is getting blanked (or set to white)
taxilian 09:10 are you drawing in response to the RefreshEvent?
neilg_ 09:10 If I click outside of the plugin instance window it happens straight away - but the contents of the window will reappear if I scroll the window
taxilian 09:10 interesting; is there anything unusual about how you are drawing the the window?
are you drawing anywhere other than the RefreshEvent?
neilg_ 09:10 No - and perhaps that might be the crux of the the problem
Yes and yes unfortunately
Everything's being drawn asyncronously by Direct3D
taxilian 09:10 ok
make sure you are handling the refreshevent
even if that means just telling your other thread to redraw
neilg_ 09:10 Yup, I am (just returning true for now - is that enough?)
taxilian 09:10 probably not
if you don't do a basic draw in response to a WM_PAINT, it will keep calling WM_PAINT over and over
it's kinda weird
also, you need to actually redraw
because WM_PAINT is called to invalidate the window, which means you have to redraw or something will not look right
so if your D3D doens't redraw on WM_PAINT, most likely something is drawing over your window and then telling you to redraw yourself and you aren't doing so
neilg_ 09:10 Well, the weird thing is that it _is_ drawing still - I just can't see it unless I use the browser scroll bar
taxilian 09:10 at best you'll get flickering, at worst you'll get what you're seeing
well, I would try handling the WM_PAINT event correctly first
neilg_ 09:10 I do suspect it's related to WM_PAINT though so I'm not discounting that. :)
taxilian 09:10 if that isn't it, we'll look at something else
you need to do at least this when you handle RefreshEvent:
HDC hdc;
hdc = BeginPaint(m_hWnd, &ps);
// Release the device context
EndPaint(m_hWnd, &ps);
neilg_ 09:10 Though I've also tried just using the default FB behavior of calling BeginPaint() and EndPaint() to see if that worked
Yep, I did :)
taxilian 09:10 yeah; that'll help
but you need to redraw as well
are you creating a new window or anything?
neilg_ 09:10 Nope, nothing like that
taxilian 09:10 ok
try adding something to redraw when paint comes in
should be able to just signal a present on the main thread of whatever you did last
on your drawing thread
neilg_ 09:10 It's definitely redrawing constantly - I can't do much about that because it's happening asyncronously in any case
It's fine, I'm just looking for any more info as I investigate. :)
taxilian 09:10 you can use SafeQueue to send messages to your async thread
it is threadsafe
hmm. I think I've seen that issue now that I think about it
but I'm not sure what it was
I suspect something is messing up your D3D context for a brief time
and scrolling resets whatever it is
neilg_ 09:10 That's what I'm wondering too - for the same reason
taxilian 09:10 I was seeing it in firefox, though, if I'm not mistaken
we were using D3D7
neilg_ 09:10 We're using 9.0c
taxilian 09:10 we had to drop D3D9 because too many computers don't support it
neilg_ 09:10 We switched to DirectX 9.0c from OpenGL for the same reason!
taxilian 09:10 you're following in our footsteps, then… soon you too will be on D3D7 ;-)
neilg_ 09:10 Well, XP SP3 installs a version of DirectX 9.0c (I forget which version right now...) and that's the version we're targetting
taxilian 09:10 oh, the problem wasn't that DX9 wasn't installed
it just doesn't work properly on a surprising number of graphics cards
keep in mind our install base was 50 million users
so we hit a lot of edge cases
but it was something like 10-20% of our users
granted, you may know Direct3d better than we did
nirvdrum 09:10 50 million users?
What was the plugin?
taxilian 09:10 well, 50 million installs
Move Media Player
provided video streaming for,, ESPN360, and some others until less than a year ago
neilg_ 09:10 Well, I think we can get away with a bit more simply because people expect a certain baseline spec to play a 3D game
taxilian 09:10 right
your situation is a bit differe t
neilg_ 09:10 I hope so anyway!
taxilian 09:10 if you figure out what is going on, and I'm 90% sure it's D3D rather than the browser, let me know
neilg_ 09:10 So... I'm seeing the following message in Visual Studio whenever the window dissappears:
First-chance exception at 0x75b3b727 in iexplore.exe: 0x8001010D: An outgoing call cannot be made since the application is dispatching an input-synchronous call.
taxilian 09:10 set a breakpoint for that exception
find out where it is happening
neilg_ 09:10 This may be related to another really weird behaviour that I just saw - but that requires more explanation
taxilian 09:10 also keep in mind that it could be something weird with the interaction between D3D and the browser, both of which are using the same window hierarchy
neilg_ 09:10 So, I have one plugin instance which is used to check both the plugin version against what the website requires as a minimum supported version and also checks the version of local content to see whether it's up-to-date
The object tag that stores that plugin instance is then removed from the DOM and replaced with another object tag which brings in the next plugin instance which actually plays the game
taxilian 09:10 hence you need multiple mimetypes
neilg_ 09:10 Right
taxilian 09:10 fair enough
you have tested this with UAC enabled, I hope?
neilg_ 09:10 But when I scroll I'm seeing a WM_PAINT message being handled by the first plugin that now isn't even a part of the DOM anymore
And, I would assume, doesn't even have a window handle anymore
taxilian 09:10 interesting… I wonder if somehow the window isn't getting unsubclassed
not that could be a bug in FireBreath
neilg_ 09:10 It appears that way... And no, I can't see how that would be a bug in FB either :)
taxilian 09:10 sorry, I mean "now that could be a bug in FireBreath"
it actually could
neilg_ 09:10 Really?
taxilian 09:10 if PluginWindow isn't un-subclassing the window
neilg_ 09:10 I see. I was thinking more that it was an IE bug but... Now you mention it, that makes sense.
Why else would it still be getting Windows messages? Hmm.
taxilian 09:10 if you were on 1.3 I'd say turn on logging and add some messages
neilg_ 09:10 I am, I'm on RC1
taxilian 09:10 but I don't know why it wouldn't be unsublcassing
really? excelent
file logging isn't really there by default
but it will log to the debug console if you enable log4cplus
add_firebreath_library(log4cplus) in your PluginConfig.cmake
neilg_ 09:10 That exception is being thrown from within ATL. The last symbol I see is:
npSandstonePocket.dll!ATL::CComPtr<IDispatch>::GetProperty(long dwDispID=-709, tagVARIANT * pVar=Empty) Line 365 + 0x13 bytes C++
Interestingly a couple of calls before that I see:
npSandstonePocket.dll!ATL::CComControlBase::OnMouseActivate(unsigned int __formal=33, unsigned int __formal=33, unsigned int __formal=33, int & bHandled=1) Line 263 + 0xc bytes C++
And ultimately if got there because in FB::PluginWindowWin::_WinProc win->WinProc(hWnd, uMsg, wParam, lParam, lResult) returned false
taxilian 09:10 hmm. sounds like two calls being made on different threads; however, I wouldn't expect any calls to be made on other threads
OnMouseActivate is from clicking in the other area
well, I gotta run for a bit; I'll be back sometime in the next few hours =] gotta go try to finish registering for classes
neilg_ 09:10 Good luck!
taxilian 10:10 ok, back
taxilian 10:10 nirvdrum: patch for issue #93 is in both repos
kalev: just for you I applied the patch to both seperately instead of merging ;-)
neilg_ 10:10 taxilian: Early indications might be that the issue I'm seeing is because of not unsubclassing the window. This is all educational guesswork right now, I'm still looking into it... But what I do know is there are NO windows messages being processed once it "goes blank". Once I scroll it suddenly starts working again. It's very weird.
taxilian 10:10 neilg_: the easiest way to check is to enable logging and add log statements in relevant places
I wrote most of that and I haven't actually used it with a system like you're using, so there could be bugs I haven't caught
but without a plugin like that to test on, I don't know how to try to reproduce your issue
neilg_ 10:10 Is there an easy way to do that without having to rebuild using CMake again? I'd like to avoid that if possible since CMake doesn't like relative paths outside of its root and so I've modified the generated .vcproj files for now
I plan to come back to that and make it work but I was looking for the path of least resistance last week :)
taxilian 10:10 no, there is not
this is why I tell people *not* to cut corners to "get around" cmake =]
in my experience (and I've talked to a lot of people who have done that), it *always* creates more work in the long term
also, cmake works fine with relative paths if you do it right; it will just convert them to absolute in the generated project
neilg_ 10:10 Right - and it works fine so long as your relative paths are under the base CMakeFiles.txt file. Try going relative below that though and it can't find the path anymore
taxilian 10:10 nope
done it
worked fine
I'd have to see what you're doing
but it *is* possible
and it wasn't that hard
neilg_ 10:10 I've had a path under the base directory with CMakeFiles.txt finding it relatively. I've moved it down below there, added one more ".." and now it couldn't find it
taxilian 10:10 like I said; I'd need to see what you were doing
but I promise it can be done
neilg_ 11:10 Okay, I haven't gotten the logging working yet (I'll do that soon) but it definitely looks like there's an issue with FB in IE where it invalidates window handles when any plugin goes away
taxilian 11:10 ok
neilg_ 11:10 I know that's the worst kind of bug report ;) I'm looking into it though - and it doesn't seem related to subclassing at all. I've actually disabled that locally just to try and narrow down where things are going wrong
taxilian 11:10 ok; let me know what you find and if I can help somehow
actually, this is the best kind of bug report. "I found a bug… hang on, I'm still working on figuring out exactly what it is"
as opposed to: "I found a bug. you guys suck. fix it now!"
neilg_ 11:10 It _appears_ to be timing related though. Does FB even use threads? If not then it may well be timing coming from IE
taxilian 11:10 no, FB does not; it just attempts to deal with them in an intelligent way
when someone using FB is using threads
it does sound like timing coming from IE
you could try replacing all instances in ActiveXPlugin project of CComMultiThreadModel with CComSingleThreadModel
hmm. and by all instances, I mean the one in FBControl
ooh… or change the CComSingleThreadModel in COMJavascriptObject to CComMultiThreadModel
I have no idea how those got to be different, but it is somewhat worrying
neilg_ 11:10 Hmm. Interesting! I'll try that
taxilian 11:10 my gut feeling would be, though, that the way FireBreath has evolved it would be best to use SingleThreadModel
nirvdrum, any suggestions there?
neilg_ 11:10 Well, I've changed it to use the SingleThreadModel and though it isn't helped me it definitely seems like the right thing
If only because it seems like that's directly comparable to interacting with the NPAPI model
Okay! Found a solution - but there's still an underlying problem somewhere
taxilian 12:10 oh/
amackera: do you have time to finish the merge of the windowless stuff into the new Factory today?
neilg_: what was the solution?
neilg_ 12:10 Sorry, I'd have continued - I just got called away from my desk
taxilian 12:10 fair 'nuff
neilg_ 12:10 So I don't know why exceptions are being thrown (the same exception I mentioned earlier that kicked this all off) so I still believe there's an issue. However my particular issues are solved by not having FireBreath deal with Windows messages at all - I just need them all to be passed through
Once I did that everything works fine.
taxilian 12:10 could you clarify that?
neilg_ 12:10 It still deals with WM_CREATE and WM_SHUTDOWN
But I have it not calling CComControl<CFBControl>::ProcessWindowMessage locally
(and also not calling DefaultReflectionHandler)
taxilian 12:10 ok; then there is either something we're not doing right in ProcessWindowMessage or something we should be doing that we aren't
neilg_ 12:10 Right - there's totally another issue at fault here and I will continue looking into it
taxilian 12:10 sounds like you've narrowed it down, though; that's great. Sounds like a mis-handled message
also it is interesting to note that we subclass that *again* in the PluginWindowWin
so unless you've disabled that as well? it is something specific to ProcessWindowMessage
neilg_ 12:10 However I would like to push for a patch (I'll put it together) so that somebody can generate a plugin with an optional define that turns off most windows message handling within FB. The reason being that I don't need (or want) the plugin itself trying to handle messages that I want to capture myself. I mention it because I'd like to open a dialog about it. :)
Yes, I've disabled it there too although I don't think that's to blame
I don't know how you'd feel about that so I figure I'd mention it here
kalev 13:10 taxilian: hey, are you interested in taking a patch which makes a few lines of cmake code a bit uglier but also makes it compatible with cmake 2.6.0?
taxilian 13:10 depends on how ugly -[
kalev 13:10
taxilian 13:10 yeah, that should be fine
I just didn't know how else to do it
as long as you promise it works =]
kalev 13:10 Okay, I'll go ahead an commit then
It does the same thing as your code but just looks uglier
taxilian 13:10 it's not hard to understand, though
kalev 13:10 the if (TARGET ...) appeared in cmake 2.6.3 or something like that.
taxilian 13:10 ahh
okay, everyone. I need some help
I'm going to write a paper for one of my classes on Browser Plugins
and I need references :-P
the more "official" the reference the better
journals or magazines are ideal
kalev 13:10 colonelpanic blog posts? :P
taxilian 13:10 next to that things that don't arbitrarily change (like blog posts, usually, or articles) aren't bad
I will probably list those :-P He told me I could use that for one of the references =]
neilg_ 13:10 I'd love to help - unfortunately there's little documentation outside of the Mozilla wiki and your blog posts!
taxilian 13:10 yeah, that would be the problem :-P
neilg_ 13:10 The only other things I'd seen were about NPAPI:Pepper
taxilian 13:10 I should get around to reading up on that
are there any browsers that suport Pepper yet?
just FYI; whenever a browser starts to support Pepper, we will add support for it in FireBreath
neilg_ 13:10 I think Chrome does but I've only read about it - I've never tried to use it. It's not worth it to me until at least 2 of the major browsers support it!
taxilian 13:10 right
neilg_ 13:10 ...but that's another reason I like the spirit of FireBreath. Plugins are definitely an area where it makes sense to have common shared code!
taxilian 13:10 eggzaktli
neilg_ 13:10 So if I were to put together a patch for FB so that event handling could be disabled through a define is that something you might be interested in?
taxilian 13:10 I would be much more interested in you figuring out what about FB event handling breaks it =]
neilg_: did you still have the subclassing disabled when it worked?
neilg_ 13:10 Yes - I suspect it might work with it turned back on but I worry about FB taking the events that the lower layers would want to see. It might be fine if everything just returned false but..
taxilian 13:10 If FB works as designed then FB will never do that
if FB takes an event that a lower layer should see, that is a bug
the only event we do that intentionally to is WM_PAINT
the design goal of the FireBreath event abstraction is to pass the events to where they need to be and then fail back to the default if they are not handled; essentially, to expose those events to the plugin developer without requiring them to change any FireBreath code and to do so in a non-painful way
neilg_ 13:10 I may have changed the code adversely but it doesn't look like WM_PAINT is returning true (unless the plugin handles it itself)
taxilian 13:10 hmm. I believe you're correct about that
let me look at this for a second
I think there should be a return true after line 124
on PluginWindowWin.cpp
actually , it's been awhile since I've looked at this loop
but there are several propblems
neilg_ 13:10 I think I'm out of sync but from what you just told me it looks like it should return true after EndPaint
taxilian 13:10 problems
yeah, that's true
hang on; something looks weird to me here
oh, nevermind. I was looking at the wrong thing
yeah, that should return true after EndPaint
neilg_ 13:10 I'll add that, I still have some things I need to submit so that BrowserStream objects work correctly
taxilian 13:10 ok; that fix really should go into 1.3, as it is a bug, from what I can see
I'm.. really quite surprised that hasn't caused any issues
kalev 14:10 taxilian: can you take a look at ?
I'm not sure if it's the best place to fix this
currently it's easy to get a plugin to crash with running something like obj.addEventListener("asdf", NULL, false)
kalev 14:10 taxilian_away: I'm off for today, please let me know how you think it's best to fix this
taxilian 14:10 kalev: first things first, that should be if (!method)
secondly, I don't think you'll ever have that issue, because NULL doesn't get converted to a JSObjectPtr
so I don't think it's a valid case
kalev: if null were to be passed in it should just fire an exception into javascript automatically
neilg_ 14:10 Okay, so I've finally gotten around to getting everything into source control (incidentally, you know that there are different source control files in the source?). I'm going to make everything get generated using CMake
taxilian 14:10 neilg_: what do you mean by different source control files?
neilg_ 14:10 I've created a new directory, moved everything over, ran prep2008 like this: prep2008.cmd projects build -DWITH_DYNAMIC_MSVC_RUNTIME=1 -DVERBOSE=1 -DBOOST_ROOT=.\external\boost -DWITH_SYSTEM_BOOST=1
It creates the "build" directory and then dumps everything in-place anyway :-/ I guess there's a file somewhere that perhaps I shouldn't have copied?
taxilian 14:10 hmm. I don't know. there is definitely something weird that you've done
neilg_ 14:10 Well, there's all the mecurial files, there are git files and there's the .svn folder in the gecko-sdk in src/3rdparty
taxilian 14:10 try running the prep yourself
neilg_: the .svn is replaced in 1.3 or 1.4, I forget
there is only 1 .git file, and that's .gitignore (AFAIK)
neilg_ 14:10 That's the only one I noticed, I haven't looked for anymore - I just thought it was worth mentioning
taxilian 14:10 yeah, there are reasons for all of it :-P
not always good ones, but reasons =]
neilg_ 14:10 Yes. ;)
The .svn got me into a bad place though - mostly because SVN kind of sucks. :)
taxilian 14:10 well
the reason those were there
is to make it easier to update the gecko sdk headers
but it wasn't working
so I deleted the .svn dir and wrote a script to download them with curl
however, that might be in dev
so it won't hit a release until 1.4
neilg_ 14:10 I added everything to source control (we use SVN) and so the .svn folder in 3rdparty had a reference to gecko-sdk - but SVN refused to add gecko-sdk so I was in a weird state of flux!
taxilian 14:10 yeah, sorry about that
I really don't recommend putting the whole tree in your own source control, though
neilg_ 14:10 I'm not complaining (well, not to you!) - more about SVN because it's supposed to do atomic commits and clearly (in this case) didn't
taxilian 14:10 but that's because I recommend that you keep it seperate so you can easily contribute changes back and get our changes
neilg_ 14:10 Not sure what the alternative is - we have a build machine that everything has to be built by
taxilian 14:10 easy; use mercurial for firebreath
and svn for your stuff
you can then either use your own local repo or just a google code repo
depending on whether or not there are changes you're worried about
neilg_ 14:10 Not easy here though, we don't have a mecurial repo. It would be nice. I've read so much about HG and I can truly see why we should switch to it
Hopefully we can make the switch after Christmas
taxilian 15:10 neilg_: do you have changes to firebreath that you care if someone else sees?
(sorry for dropping off for 10 min, btw, a professor I'd been waiting for finally walked up)
neilg_ 15:10 Care as in want? Because for sure the fixes to BrowserStream will be useful for somebody :)
It's cool, I know how that is. Although it's colleagues and not professors for me. :)
taxilian 15:10 right; so you create a clone on google code and keep your changes there
then you just use that as your repository for firebreath and put your project in svn
anyway, that's what I'd do
but it's your choice, of course =]
neilg_: did you ever figure out what it was about the way we handle the window loop that was causing a problem?
neilg_ 15:10 Maybe. I honestly don't know that I can - at least right now. We have a build system (it's freely available called "Hudson" which manages multiple build machines) but all of that's set up to get the source from just one place (SVN). And everything has to go through the build machine because we sign everything and also upload symbols so we can track down crashes easily
Nope, I'm currently trying to get it to build using CMake. Once I have that working then I can also turn on logging. :)
taxilian 15:10 neilg_: in hudson you could just add an initial step to pull down FireBreath into your project dir; again, that's up to you. just sayin' =]
hehe. okay. let me know if I can help somehow
I'm also digging through the original macros that create the MSG_MAP
neilg_ 15:10 It may well be easy and, if so, then I'll definitely do it. I'm not discounting what you say, I'm just trying to get something working ASAP... Because we need to do as much testing as possible before the end of the week
But once I have it working I can make it work properly
taxilian 15:10 yeah, I understand how that goes
neilg_ 15:10 This isn't the way I'd prefer to develop... :(
taxilian 15:10 it's always a tradeoff
I hear ya
been there
seriously, though, if you run into problems, let me know if I can help; if you're willing to contribute, I'm willing to help however I can
wtih the proviso that I won't write all your software for you for free ;-)
neilg_ 15:10 Well what good are you?! ;)
Thanks for the offer though. :)
taxilian 15:10 heh
I can help you figure out the hudson script if you need, though
Firebreath's automated test builds are at
neilg_ 15:10 I'm definitely going to contribute back - we've already agreed internally that if I found any problems with FB that we were happy to commit back
taxilian 15:10 good to hear -=]
neilg_ 15:10 Since we're going to be relying on FB now I personally think it's only fair! :)
taxilian 15:10 not just fair, but smart
we benefit from your contributions, but you benefit from others using your code contributions, finding bugs, and improving them
neilg_ 15:10 Exactly
Nobody is perfect. I'm certainly not! And though I like to think I write bug-free code... Experience has taught me otherwise. :)
taxilian 15:10 oh, my software is 100% bug-free
it has been known to occasionally generate random features, however
neilg_ 15:10 I like to think of them as undesigned features
taxilian 15:10 I had a tester once who would send me messages with "I found an undocumented way to exit the program!"
neilg_ 15:10 Oh, oh, oh, I can't even go there in public. But I've had some doozies in the past!
taxilian 15:10 hehe
taxilian 15:10 neilg_: So I went back and reconstructed the originally ProcessWindowMessage from the macros
that's what the ATL control does with no changes for that function
neilg_ 15:10 Do you not need to handle WM_CLOSE and WM_DESTROY there to clean up the plugin instance?
taxilian 15:10 gotta run to my next class; be back on in a bit
we do
that's why I added them
what I'm saying is that what I pastebined is "known good"
it *shouldn't* cause any problems
because it's exactly what Microsoft's wizard generates
neilg_ 15:10 Ah, completely with you now. In which case... looks good!
taxilian 15:10 neilg_: I thought that might help you track down what is going on
neilg_ 16:10 Yup, I think it will too. I have that open in a tab right now for me to look at later/tomorrow
Thanks :)
taxilian 16:10 np
neilg_ 16:10 I'm off, catch you all tomorrow. Bye!
nirvdrum 16:10 How trustworthy is the on-the-fly cmake modifying sln and prj files?
Should I just be running the prep command anyway?
taxilian 16:10 well, it seems to work just as well, but...
it also has to stop the build to reload the project
which makes it pretty useless
so I just run the prep command
nirvdrum 17:10 taxilian: The JSObjectPtr fix looks like it's working.
taxilian 17:10 excelent!
is there a noticable performance hit to it?
nirvdrum 17:10 At least, the error doesn't show up. I haven't checked if it's actually freeing memory :-P
taxilian 17:10 lol
pretty sure it is =]
otherwise it would never return
the destructor blocks on the call to the main thread
nirvdrum 17:10 I haven't profiled, but the plugin is so heavily bound to generating a screenshot, that I really wouldn't notice the freeing issue unless it were ridiculously slow.
taxilian 17:10 yeah
I don't think it'll be an issue
just still debating whether or not I should have made that asynchronous =]
taxilian 17:10 amackera: haven't heard from you all day. you around?
nirvdrum 17:10 taxilian: How should I go about adding additional exports to the .def file?
taxilian 17:10 nirvdrum: err, yeah, about that… currently, there is no good way
I'm open to suggestions
or you could just hack it
nirvdrum 17:10 Okay, no CMake incantation for that then?
taxilian 17:10 really, though, I think the best way would be to update the way that the generated files work and allow you to specify your own
not yet
nirvdrum 17:10 I just realized I've been tracking down an issue for a couple hours related to a change I lost on the upgrade.
taxilian 17:10 there really should be
nirvdrum 17:10 I really should set up that friggin' logger :-P
taxilian 17:10 what is the change?
the export?
nirvdrum 17:10 Yeah. It's a mega hack, but I expose a CallWndProc hook in the DLL.
I need this so I can modify a particular message as it gets posted.
taxilian 17:10 yeah… that's definitely a serious hack =]
but we really need a good way to specify your own .rc file, .def file, etc
nirvdrum 17:10 It's basically the same technique as I used for SnapsIE:
taxilian 17:10 that's on the list of "things that I thought we'd eventually want but didn't take the time to do back before anyone used it"
nirvdrum 17:10 Heh.
Well, if I can ever really wrap my head around the project, I'd love to be able to contribute something like this.
I'll take another stab after 1.3 is finished since it sounds like the APIs will stabilize around then.
taxilian 17:10 well, I can point you at the relevant sections, if you want to try it
it's technically not a very difficult problem
nirvdrum 17:10 I really should just buckle down and learn cmake.
taxilian 17:10 this stuff will almost definitely not change before 1.3
so you could put it in dev
nirvdrum 17:10 I was happy to just consider it a build dependency, but it seems it's really a configuration tool with regards to FireBreath.
taxilian 17:10 it really is
if you want to get the most out of the framework
nirvdrum 17:10 So, I just need to lose the bitter taste m4 left in my mouth a decade ago :-)
taxilian 17:10 I keep wanting to really write some good docs for using cmake
well, if you want to dive in a bit, it's not hard to understand how the .def file gets there
and you could probably add a PluginConfig.cmake option to get it from another location
nirvdrum 17:10 Sure, point the way. I doubt I'll get a chance to spend significant cycles on it before the weekend, but it'll give me something to play with while 1.3 gets out the door.
taxilian 17:10 great
you can help me design a solution
one sec
so the gen_templates/ directory in the root
has files that are templates
and filled out by cmake mostly from PluginConfig.cmake
go ahead and look at them, though; they are really dead simple
nirvdrum 18:10 Okay.
I see the .def file in there.
taxilian 18:10 yep
you may also see that there aren't actually any templated variables in it =]
nirvdrum 18:10 Indeed :-)
Well, other than the plugin name at the top.
taxilian 18:10 basically, somewhere (trying to find it) there is code that loops through all of the files in that dir and uses the configure_file cmake command on them
it might be in cmake/
yeah, there it is
basically, when cmake is generating the build files, we copy this to each plugin project dir
some of hte projects (the ones with the prefix brefore them) are generated for each plugin projcet
ActiveXPlugin is one of them
so when this file runs, ${CMAKE_CURRENT_SOURCE_DIR} is the src dir of the plugin
${CMAKE_CURRENT_BINARY_DIR} is build/projects/<PluginName>/
nirvdrum 18:10 Honestly, I still don't get why some things start with the prefix and some don't.
taxilian 18:10 ok
ActiveXPlugin needs certain include files
and they have to be plugin project specific, right?
GUIDs, names, etc
nirvdrum 18:10 Yeah.
taxilian 18:10 so unlike ScriptingCore, which is the same for all plugins
ActiveXPlugin is different for each plugin
nirvdrum 18:10 But they both get generated to my build directory, no?
taxilian 18:10 it has a plugin-specific .rc, .def, several config files, etc
ScriptingCore gets generated for all plugins
and ActiveXPlugin gets generated under your mogotest plugin project dir
if you do a prep for examples
you'll find buildex/src/NPAPIHost, PluginCore, ScriptingCore, ScriptingCoreTest, unitteest-cpp
no activexplugin
nirvdrum 18:10 Okay, taking a step back, is the idea that someone might have two plugins in the same project?
taxilian 18:10 buildex/projects has FBTestPlugin and BasicMediaPlayer
nirvdrum 18:10 Ahh.
Well, that clarifies a lot.
taxilian 18:10 you can have as many plugins as you want in the projects/ dir
I may remove that once we have support for multiple plugins in a single DLL
because my need for it has gone away
and it seems to confuse people a lot
nirvdrum 18:10 So, you could actually do the prefix for everything and just duplicate the libs. I'm not saying it's a good idea, but it'd be an option.
taxilian 18:10 I could; I have been trying to keep from having plugin-specific stuff whenever possible
but that's another argument for another day =]
nirvdrum 18:10 The mistake I originally made is I assumed everything that started with MOGO meant I could screw around with it.
taxilian 18:10 sorry :-/
nirvdrum 18:10 Eh, it's a learning process.
I still owe you some wiki docs, so good for me to learn this ;-)
taxilian 18:10 hehe
so anyway, line 44 of
as it loops through all of the template files
probably the easiest thing to do would be to add a if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/${TemplateFile}) section
and if that exists, configure_file it instead of the one in gen_templates
then you could override any of those simply by putting it in your project directory
now that I look at it, I guess I could do it myself pretty easily
unless you want to for the practice =]
nirvdrum 18:10 If I'm truly the only guy that needs it, I don't mind doing it for practice.
It just will likely take longer.
taxilian 18:10 nah, others need it too… it's just a question of when =]
nirvdrum 18:10 Heh.
taxilian 18:10 like I said, I've thought about this before
nirvdrum 18:10 Well, like I said, I could probably look at it this weekend. I've just got insane backlog of other stuff to crank through this week.
taxilian 18:10 eh, I can throw it in there real quick
if I throw it in 1.3, can you test it real quick?
nirvdrum 18:10 Yeah.
Woo hoo. I finally have a built DLL working with 1.3.
taxilian 18:10 yay!
is that with RC2?
nirvdrum 18:10 With -dev as of about an hour ago.
taxilian 18:10 ahh
nirvdrum 18:10 I needed that memory fix.
taxilian 18:10 that's actually pre-1.4, then =]
nirvdrum 18:10 Heh.
taxilian 18:10 I put the memory fix in 1.3 as well
but I'm pretty confident that from this point the API should be pretty stable
nirvdrum 18:10 It looks like document.body.scrollHeight works reliably, whereas document.height can return undefined in cases.
taxilian 18:10 that factory change makes a surprisingly big difference
nirvdrum 18:10 Hopefully switching to scrollHeight doesn't cause issues elsewhere.
Otherwise I could catch the undefined error and fall back to scrollHeight. It'd just be uglier.
taxilian 18:10 yeah
go ahead and do a pull
if your'e on dev, you should have the change
just copy the .def file to your plugin dir
and modify it
should work
see the advantages of hanging out in the IRC room? Features on-demand ;-)
nirvdrum 18:10 Heh.
taxilian 18:10 let me know if that works
nirvdrum 18:10 Man, I really need to read up on mercurial. I don't think I've gotten an update to just work.
taxilian 18:10 lol
nirvdrum 18:10 It doesn't really work the same way as SVN or git and those are my two reference points.
taxilian 18:10 yeah, it's a little difference
nirvdrum 18:10 I did pick up the O'Reilly book for hg, just haven't had the time to read it.
taxilian 18:10 well, that's more than I've done
I just muddle through
nirvdrum 18:10 Didn't seem to pick up the template. I'm digging in a bit more.
taxilian_away: The predicate in the if statement at the start of that loop needs to be: EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/${CURFILE}
After making that change, it works fine.
taxilian 19:10 nirvdrum: oops =]
you added NOT before EXISTS?
that isn't what you want
TemplateFile should be CURFILE on that line
nirvdrum 19:10 No, the "Not" was just the way I started that sentence.
I missed the quotes on that one.
taxilian 19:10 your second line must not have come through, then
I pushed the change, will put something up to test it now
nirvdrum 19:10 Thanks though. That did do the trick.
taxilian 19:10 it's working now in dev
is that what you'd changed?