Open GoogleCodeExporter opened 8 years ago
Have you tried this with the latest from 1.4? There have been some significant
changes to the streams in 1.4 that may have fixed this issue.
Original comment by rich...@firebreath.org
on 7 Jan 2011 at 4:38
No, I did not. I will try to test it this weekend, otherwise I'll check it on
Monday.
Original comment by noant...@gmail.com
on 7 Jan 2011 at 8:57
I have tested the FBTestPluginAPI::testStreams() using the master git branch
and the commit 57f2c49c357697bfa78202c6e0273fcbd5d9dbe8 (lastest 1.4 version),
but the streams still do not work running.
I tested on FireFox 3.6.13, FireFox 4.0 b8 and Chrome v8.0.552.224 (in all
tests I have used Debug version). Testing FBTestPlugin on IE v8.0.7600.16385 I
get another error, an assert happens running FBTestPluginAPI at PluginCore.cpp
line 111.
Note: I have not tested in release mode.
Original comment by noant...@gmail.com
on 10 Jan 2011 at 11:29
I've updated my plugin to 1.4 (nightly 74). It's downloading streams
successfully from IE8 and FF3.6 on Win7. I've handlers for stream created,
opened, data received, and completed. So, I can confirm these events are
properly sent.
Original comment by kcs...@gmail.com
on 13 Jan 2011 at 8:53
Hi kcsham,
Which git's branch are you using? Which commit (hash number)?
Best regards.
Original comment by noant...@gmail.com
on 13 Jan 2011 at 9:19
It sounded like we my have resolved this is an issue with not holding a
reference to the stream objects until the download completed; is this correct?
Original comment by richarda...@gmail.com
on 29 Jan 2011 at 2:05
I'm afraid that I'm experiencing similar symptoms with 1.4b3. Stepping through
the code, it looks like only 2 observers are being registered by the base class
(DefaultBrowserStreamHandler) though my derived class overrides all event
handlers. It appears that just as I'm about to receive a data event,
BrowserStreamManager calls its onStreamCompleted() handler and removes my
observers.
Original comment by Geoff.Cu...@rogers.com
on 31 Jan 2011 at 2:07
Keep in mind that BrowserStreamManager only removes defunct weak_ptrs and it's
own handler, so if your handler is gone after that then you have failed to
retain your own shared_ptr to the observer.
This is by design; there is no hard link between the stream and your observer
so if your observer goes away early for whatever reason it doesn't cause a
crash. Try saving a shared_ptr to your observer in your class and see if the
problem goes away.
Original comment by taxilian
on 31 Jan 2011 at 2:10
That was the problem. Thanks!
Original comment by Geoff.Cu...@rogers.com
on 31 Jan 2011 at 3:24
I'm going to mark this resolved, then; we'll need to add that to the docs.
Original comment by taxilian
on 31 Jan 2011 at 3:30
Original issue reported on code.google.com by
noant...@gmail.com
on 29 Dec 2010 at 10:05