IRC Log Viewer » #firebreath » 2017-01-25

IRC Nick Time (GMT-7) Message
taxilian 09:01 Alex_SG I suspect the issue he's having with IE has to do with something that was never finished. IE support was one of the things that I didn't complete; I think someone else did a lot of the work, but I'm not sure it's all done
sergio_ 10:01 hi
taxilian 10:01 hello
Guest49139 10:01 hi richard
I am trying to debug the seg faults on the plugin when compiling with msvc 2015
taxilian 10:01 my guess is that there are some fundamental pieces of the ie support that haven't been finished yet
when in doubt, see what happens on firefox/npapi for comparison
I have verified that the native messaging stuff works
in 2015
Guest49139 10:01 can I ignore the problem with postURL ?
i mean, is it supposed to work? or I should just remove it from the tests?
taxilian 10:01 in theory I think it should work, but it may need to be updated
looks like the issue is a null pointer; have you stepped back in the stack to see what calls it?
Guest49139 10:01 I think that the problem is that createStream is returning a null stream
have not checked deeper into that
taxilian 10:01 on IE it uses windows APIs to simulate the stream stuff that firefox has built in, so it should be able to work fine
Guest49139 10:01 couriously the getURL is working
Guest49139 10:01 ok, I will check more tomorrow my time and let you know if I find anything new
Alex_SG 17:01 0taxilian: just to make sure I understand correctly, IE plugin with version 1.6 work, IE plugin with version 2.0 using msvc 2013 seem to work OK (pass all the tests).
it s only when we compile with 2015 that we seem to have problem. SO why do you think the problem comes from the code itself, and not the compiler?
taxilian 17:01 interesting; I did not know that msvc 2013 passed that particular test
but still; it's clear that it's a change in 2015 that has caused the issue, but that doesn't mean it can't be fixed
Alex_SG 17:01 true.
serti worked on it before sergio
and it had everythign working with msvc 2013
I did not check directly myself,
taxilian 17:01 interesting
Alex_SG 17:01 but with his modificatiosn to the code, and to the example
it came to work on mac as well
so I could check on my side that he had fixed on mac
and he sent me screenshots of IE on win7 with msvc 2013
he couldn t fix msvc 2015, and had family issues, so I brought sergio in
so I’m not totally convinced that the code is the culprit ....
taxilian 17:01 I'm not sure I understand what you mean; are you saying you don't think there is a way to fix it?
Alex_SG 17:01 So now the question is: what is the best way to narrow down on that bug (and rub it in MS face if need be)
no, I think the code itself works, but the problem is on the compiler side.
but as long as we don;t understand what the compiler is doing (implicitely), there s nothign we can do.
taxilian 17:01 certainly the likely problem could be described in two ways: 1) the code is incorrect because it no longer works with the updated API, or 2) the libraries have changed and broken the build
Alex_SG 17:01 my comment relate to you saying “I’m not sure I ever finished the IE part"
taxilian 17:01 As far as I know we haven't come close to finding what is actually happening; there is a lot more we can learn. somewhere an API is being called and it isn't returning what we expect
Alex_SG 17:01 and my answer to that is “as far as the FBTestPlugin goes, and with msvc 2013, it seems to be OK"
taxilian 17:01 that's good news =]
Alex_SG 17:01 agreed on your last comment. and sergio is digging right now.
now, I’m not sure how much of the code the FBTestPlugin is actually covering.
taxilian 17:01 so two paths can be taken: 1) we can try to fix it so that we have full functionality or 2) we can leave it be until someone who needs it gets desperate enough to fix it themselves =]
Alex_SG 17:01 yeah, right, I’m desperate enough :D ha ha ha
taxilian 17:01 it tries to be fairly comprehensive, but there are a lot of edge cases around in there
well, but in fairness you don't actually have to have that API working AFAIK
so you could disable the check and just ignore it
Alex_SG 17:01 so that s one of the question I wanted to ask later but it might be the right time
taxilian 17:01 I personally would be happier if we figured out how to make it all work, but I wouldn't blame you for doing so
Alex_SG 17:01 is there any unit test per say ?
and is there any other tst we oculd run automtaically to catch regression
taxilian 17:01 there were in fb1, but I never updated them for fb2 :/
Alex_SG 17:01 :)
taxilian 17:01 it got complicated quickly by the new promise framework
in the tests directory
if you build the master branch you'll see unit tests run
Alex_SG 17:01 setting up the FBTestPlugin automatically on appveyor and travis saved us a lot of efforts
ok, reference: master: unit tests.
on the part you are most interested in: the firewyrm, is there anything we could run to test for regression ?
taxilian 17:01 FBTestPlugin could certainly be run via firewyrm
firewyrm is currently only used to load the plugin via native messaging
Alex_SG 17:01 you mentionned that others had been reporting crashes with native messaging
taxilian 17:01 unit tests could be written to exercise the firewyrm interface either with our without a browser
they were; I've fixed that crash
Alex_SG 17:01 is there anything today we could run automatically to catch that
taxilian 17:01 test.html could be updated to work on Chrome
Alex_SG 17:01 which test.html ? the FBTestPlugin one ?
taxilian 17:01 yes
Alex_SG 17:01 ok, i write it down.
got it.
taxilian 17:01 I'm not sure how useful that'd be, but it should be possible =]
Alex_SG 17:01 :)
let’s fix what we have now
taxilian 17:01 I always thought it'd be interesting to try writing a node.js firewyrm host =]
Alex_SG 17:01 so, you mentionned above that I could just comment out the problematic API today, why is that? Is it not needed for npapi plugins in general ?
taxilian 17:01 well, it's not needed unless you happen to need it. not all plugins use all functionality
it's not a fundamentally required API, it's just a feature that allows you to use the browser to POST data from within the plugin
Alex_SG 17:01 then, regarding the postURL, when serti asked you a few months back, you mentionned it was deprecated. You gave a different answer today.
I see.
taxilian 17:01 hmm. I guess it kinda could be
Alex_SG 17:01 yes, in our case, it is unliekly that we need it. however, if we decide to ignore it, we should document it so other people don t stumble on the same stone.
taxilian 17:01 I'm not sure that I ever implemented it for FireWyrm
so that may be why I said it was deprecated; not sure it really works well in fb2
I suppose on further thought I could possibly be convinced that the whole browserstreams api should be removed
Alex_SG 20:01 and then, only a few, or no people stand up, we remove it?
point me to them, let s document that, and I ll get students to fix it
that s what internships are for :D
equivalent to the FBTestPlugin ?
taxilian 17:01 if everything is working as it should then FBTestPlugin should work on all browsers regardless of how it runs -- npapi, activex, or native messaging
FireWyrm was designed to be an asynchronous protocol which can work over essentially anything; you could make a version that worked over AJAX if you wanted to
I'm too far out of the code these days and I'm losing track of things, unfortunately