|IRC Nick||Time (GMT-7)||Message|
|FireBreathBot||01:05||JIRA issue http://jira.firebreath.org/browse/FIREBREATH-64 issue created by dougma|
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 http://jira.firebreath.org/browse/FIREBREATH-65 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" http://goo.gl/FQDFu
Commit 2a132f8 on firebreath-1.5 by Richard Bateman: "FIREBREATH-62 Updated async method firing to use js delegate..." http://goo.gl/Ktz0C
Commit 732a72f on firebreath-1.5 by Richard Bateman: "FIREBREATH-62 fixed async arguments" http://goo.gl/zOyT6
Commit d3c6db0 on firebreath-1.5 by Richard Bateman: "FIREBREATH-62 Fixes for IE w/ new async method" http://goo.gl/BScyd
Commit 4ddb52a on firebreath-1.5 by Richard Bateman: "Fixed tab inconsistencies" http://goo.gl/FQDFu
JIRA issue http://jira.firebreath.org/browse/FIREBREATH-62 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 http://goo.gl/zOyT6|
|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||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)...it 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
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?
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..." http://goo.gl/vbae8|
|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..." http://goo.gl/vbae8|
|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|
|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 app..it's sort of a nightmare|
|taxilian||10:05||lol. I believe that|
|FireBreathBot||11:05||Commit 363505e on master by dougma: "invalidate entire control" http://goo.gl/CXCat|
|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" http://goo.gl/KyRpI|
|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
|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 http://jira.firebreath.org/browse/FIREBREATH-64 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 http://jira.firebreath.org/browse/FIREBREATH-65 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 http://jira.firebreath.org/browse/FIREBREATH-65 issue updated by richard
|taxilian||11:05||random FireBreath trick of the day: http://www.firebreath.org/display/documentation/Tips+and+Tricks#TipsandTricks-GettingthevalueofGETvariablesfromthequerystring|
|FireBreathBot||14:05||JIRA issue http://jira.firebreath.org/browse/FIREBREATH-66 issue created by jloveridge
JIRA issue http://jira.firebreath.org/browse/FIREBREATH-67 issue created by jloveridge