|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|
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
|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
serti worked on it before sergio
and it had everythign working with msvc 2013
I did not check directly myself,
|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 :/|
|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 ?|
|Alex_SG||17:01||ok, i write it down.
|taxilian||17:01||I'm not sure how useful that'd be, but it should be possible =]|
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.
|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