89270 - Mozilla destroys the stream when NPP_WriteReady() return 0

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[alain]

According to the Plugin documentation, flow control can be achieve :
"If the plug-in receives a value of zero, the data flow temporarily 
stops. Communicator checks to see if the plug-in can receive data again 
by resending the data at regular intervals. "

Excerpt form NPP_WriteReady() description in the plugin ref.

But instead Mozilla destroy the stream when 0 is return and no longer
call NPP_Write at regular interval

Comment 1

[Peter Lubczynski]

See bug 86473 to suspend a HTTP channel.

Comment 2

[Peter Lubczynski]

alain: do you have a testcase or tester plugin for this?

Comment 3

[Peter Lubczynski]

I think Darin put in the ability to pause a stream a while ago and this should
be done before mozilla1.0

Comment 4

[Peter Lubczynski]

nominating nsbeta1

Comment 5

[Jaime Rodriguez, Jr.]

nsbeta1+ per ADT Triage.

Comment 6

[rubydoo123]

Where is the test case? Or where is a site that demonstrates this issue? Seting 
to nsbeta1- until either a valid test case is attached or a URL pointer is 
attached. Also moving to moz1.1

Comment 7

[Peter Lubczynski]

-->serge

Comment 8

[saari (gone)]

topembed- until we get a testcase. Nice to fix category

Comment 9

[Denis Antrushin]

removing myself from cc:

Comment 10

[Jack Xie]

This appears to be the reason Plugger does not work in streaming mode.  As soon
as the buffer is filled and a write fails with EAGAIN, Mozilla stops sending
data to the plugger.  In netscape, NPP_Writeready is called periodically, even
when it returns 0, and eventually the write's will succeed, WriteReady will
return a value > 0, and the streaming resumes.

Comment 11

[Peter Lubczynski]

*** Bug 195638 has been marked as a duplicate of this bug. ***

Comment 12

[Peter Lubczynski]

-->peterl

Comment 13

[Lindsay]

I'm seeing this problem with Mozilla 1.6 and plugger 4.0, although I suspect it
may be a plugger problem.  Please see bug 235641 for details.

It looks as though plugger may be trying to stream mp3's, and from reading this,
it looks as though mozilla is failing to negotiate properly with the plugin, so
this may be a two headed problem.  My understanding is that because play rates
may exceed transfer rates on a slow Internet connection, a browser and/or plugin
fed an explicit link to an mp3 file should not try to stream it, but should
download it in its entirity and then play it.  Streaming (actually
pseudo-streaming) is the job of the processing chain attached to the m3u file
format, which does work propoerly in mozilla (on my system, XMMS gets invoked to
handle the m3u indirect reference).

Comment 14

[Johnny Stenback (:jst)]

Fixed by the change in bug 216218 (which should really have been a dupe of this
bug).