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

IRC Nick Time (GMT-7) Message
FireBreathBot 01:05 JIRA issue issue created by dougma
Michael 09:05 Hello, all
Guest35428 09:05 Hello
I have a question about how to draw graphics using firebreath, anyone can help me?
Dave 10:05 Does firebreath work with x64 ie?
FireBreathBot 10:05 JIRA issue issue created by capsel
taxilian 10:05 dave: no, it doesn't
or is dave now Guest2410? Well, whoever ask about x64 IE, no; nobody really uses it so far (That I can tell) so I haven't bothered working on 64 bit support
probably wouldn't be hard to add, but no real point as of yet
FireBreathBot 10:05 Commit 4ddb52a on master by Richard Bateman: "Fixed tab inconsistencies"
Commit 2a132f8 on firebreath-1.5 by Richard Bateman: "FIREBREATH-62 Updated async method firing to use js delegate..."
Commit 732a72f on firebreath-1.5 by Richard Bateman: "FIREBREATH-62 fixed async arguments"
Commit d3c6db0 on firebreath-1.5 by Richard Bateman: "FIREBREATH-62 Fixes for IE w/ new async method"
Commit 4ddb52a on firebreath-1.5 by Richard Bateman: "Fixed tab inconsistencies"
JIRA issue issue resolved by richard "I think this issue is fixed; please test and confirm that it is working."
cstevens 10:05 taxilian: speaking of those commits, 732a72f breaks some of my callbacks since it drops the calling context. is that intentional?
FireBreathBot 10:05 732a72f by Richard Bateman: FIREBREATH-62 fixed async arguments
taxilian 10:05 cstevens: the calling context meaning "this"?
what was the context before?
cstevens 10:05 yeah. before, doing callback->InvokeAsync() would have the callback object be "this"
now it's the main dom window
taxilian 10:05 what browsers did you test that on?
'cause I'm pretty sure that wasn't consistent across browsers
cstevens 10:05 FF 3.6 and FF4
taxilian 10:05 platform?
cstevens 10:05 Win7
taxilian 10:05 interesting. I'm pretty sure IE wouldn't have worked that way
cstevens 10:05 it's going to be the same for all FF, though, because of how apply() works
taxilian 10:05 well, now it would be… previously we weren't using apply
cstevens 10:05 it has to do with using apply(null, args) will always use the global object for "this" in that case
taxilian 10:05 I'm open to the possibility of changing it; however, I'm not sure if there is a consistent way to do so that would make more sense
yeah, I'm aware of that
I mean previously
the way it was before
it was inconsistent, I think
now it would at least be consistent
I'm open to the idea of changing it to be consistently something different than window, but I'm not sure what/how that could be reasonably done
cstevens 10:05 yeah, i don't have any suggestions on that, since i don't do any dev with other browsers right now
taxilian 10:05 the problem is that when we call the function we don't have any context… I know what function object we're calling, but not what object is firing the event
in javascript the standard is that events are fired from window… (stupid standard, but at least this is consistent)
can you live with the way it works now? (I usually pass shared_from_this as one of my arguments to the event, personally)
cstevens 10:05 in the 4 argument case, you do have the "owner" object for the function
in BrowserHost.cpp:138, you call "f[fname].apply(null, args)", and that could maybe be changed to "f[fname].apply(f, args)"
i can live with it. not a big deal to add an argument on the front
taxilian 10:05 yes, I could change that… would it help?
and then if a method object is called directly it has no context, just window?
does that make sense in JS?
cstevens 10:05 that just means that the object the function is defined on will be "this"...i do that in my javascript all the time with callbacks
the main worry i have is that it won't be consistent across browser
my project is entirely in firefox (xulrunner app, actually)
FireBreathBot 10:05 Commit 25665a7 on firebreath-1.5 by Richard Bateman: "FIREBREATH-62 Updated callback delegate to keep object conte..."
cstevens 10:05 and yes, if a method object is invoked directly, it just uses the window
FireBreathBot 10:05 Commit 25665a7 on master by Richard Bateman: "FIREBREATH-62 Updated callback delegate to keep object conte..."
taxilian 10:05 like that?
!findfile URI.cpp
FireBreathBot 10:05 Found 1 matching file(s) in the master branch. First 1 are:
cstevens 10:05 wow, quick service around here! :) yeah, that works
thanks! (also, for firebreath in general. great platform)
taxilian 10:05 I'm happy to help… I do ask in return:
please help update docs, or contribute in whatever way you can
this is a heck of a lot of work and most of it I'm the only one currently around that knows how to do =]
it's a lot easier when people help out even in little ways… like updating docs on the wiki, or sending a few bucks to pay for hosting, or answering people's questions, etc
there is plenty to do =]
cstevens 10:05 yeah, i can imagine. i'll do what i can
taxilian 10:05 thanks
cstevens 10:05 i don't have a lot of cross-browser/cross-platform experience, but i've been working w/ NPAPI for a while
taxilian 10:05 excelent! you can help keep me honest =] just wish there were more COM guys around… but those are pretty rare
that's where we tend to have the most problems
what do you think in general of my solution to the ff4 issues? (with the callback delegate)
cstevens 10:05 yeah, no kidding. i'm actually using firebreath to embed a COM webbrowser control in a xulrunner's sort of a nightmare
taxilian 10:05 lol. I believe that
FireBreathBot 11:05 Commit 363505e on master by dougma: "invalidate entire control"
cstevens 11:05 the callback delegate's a good idea, if it was concurrency related. i don't really know what the root problem was
we still haven't moved up to xulrunner 2.0 (ff4) yet, since there's some changes to the XPCOM components that we need to address
taxilian 11:05 there are a few issues we ran into wtih ff4
the first is that when we called onload, the NPObject wasn't yet hooked up to the DOM element in some cases
which is, in a word, weird
the second is that for some reason anytime we call Invoke on an NPObject and something blocked (like an alert) the browser process would hang
disconnecting it by using the delegate gave us two advantages; the first is allowing a 250ms delay on the onload callback, which seems to be enough on all machines I've tried to have the element hooked up
cstevens 11:05 we're seeing something like that in FF3.6 sometimes...only when IPC is enabled, though
taxilian 11:05 the second is that it breaks it from the thread and prevents reentrance issues
it's IPC related
this should probably fix that
FireBreathBot 11:05 Commit 0dee977 on firebreath-1.5 by dougma: "FIREBREATH-64: invalidate entire control for ax windowless"
cstevens 11:05 it very close to my own solution...when in doubt, setTimeout() ;)
they changed some of the thread handling w/ FF4 as well, which is our main stumbling block
taxilian 11:05 yep
cstevens 11:05 we were using some background workers, which don't work the same way any more
taxilian 11:05 actually I'm kinda glad we finally had to inject a JS function; now I can use what I have to inject a few more if needed
maybe add support for "new object.." style calls, which we can't do with raw NPAPI
FireBreathBot 11:05 JIRA issue issue resolved by richard "This isn't really the way that I want to fix this in the long run, but it's better to have an uns..."
JIRA issue issue commented by richard "interesting; I don't know that code very well, so it may take me awhile to find time to work on i..."
JIRA issue issue updated by richard
taxilian 11:05 random FireBreath trick of the day:
FireBreathBot 14:05 JIRA issue issue created by jloveridge
JIRA issue issue created by jloveridge