79944 - Image decoders ProcessData() returning zero behavior

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[tor]

I'm not sure whether this is a libpr0n or necko problem, so both are
CCed.

I'm working on the MNG/JNG image decoder and am seeing some strange
behavior.  The libmng library does restartable demand reading of data,
and during pauses of the animation isn't ready for any input.  I don't
want to add another layer of buffering into nsMNGDecoder so ProcessData
returns zero for the handled count.  Something further upstream
appears to take offense to this, as nsMNGDecoder::Close is called
shortly after, long before all of the stream has been pushed through
the decoder.

Is this the expected behavior?  If so, any suggestions on how to work
around it?

Comment 1

[Stuart Parmenter]

if you return NS_ERROR_* to WriteFrom(), it will cause the stream to get closed.

Comment 2

[tor]

That's not it - nsMNGDecoder::WriteFrom() always returns NS_OK.

Comment 3

[tor]

In particular:

  WriteFrom returning 0 count=160408 _retval=21238

21238 is indeed how much of the stream was handled.  ProcessData only sees
slightly more (3072 bytes) of the stream.  About 140k slipped away somewhere.

The output stream methods of the MNG decoder are modeled after the PNG decoder,
for what it's worth.

Comment 4

[benc]

mass move, v2.
qa to me.

Comment 5

[Darin Fisher]

i believe the problem has to do with the fact that necko will not send you a 
final OnDataAvailable.  as i once said: necko expects a stream listener to 
consume all data specified by an OnDataAvailable call.  while i agree that this
is not exactly convenient and arguably somewhat broken, it is the current
behavior.  i could probably fix this in nsStreamListenerProxy, which would 
help in most cases (http, ftp, file, etc.)... but this likely does not cover
all call sites of OnDataAvailable.

Comment 6

[Darin Fisher]

-> future

Comment 7

[benc]

Is this all plats?