NPP_WriteReady returning zero hangs URL until you clear cache or restart Firefox

RESOLVED FIXED

Status

()

--
major
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: mr.jack.reed, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

I am porting a plugin to Firefox.  This plugin requires the ability to throttle HTTP streams.  It is doing this by using NPP_WriteReady to return zero to temporarily halt the stream until buffer space is free.  A problem arises in Firefox 2.0.0.8 if you destroy the stream while the stream is halted in this way.  That URL will no longer work until you either clear the browser cache or restart the browser.  For example if you change the browser page while the stream is stopped and the stream and plugin are destroyed you get in this mode.  If you then come back and try to display the same URL again the stream is still blocked until you clear the browser cache or restart the browser.

It appears there is some flag set in the browser cache on the stream used to halt the stream and it doesn't get properly cleared when the stream is destroyed.  It persists in to the next stream instance created on the URL until you clear the cache.

Unfortunately this is a proprietary plugin so I can't easily provide a test case.  I'm hoping this rings a bell with someone who knows the stream code and maybe you can just make sure this flag in the stream cache is cleared when the stream/plugin is destroyed, or when its reopened, so the stream will work the next time around.  

I'll continue to look for a workaround.  The only one I can think of requires I delay closing the stream and destroying the plugin until NPP_WriteReady is called again so I can return a non zero value.  Its awkward delaying destruction of a plugin when a page is unloaded though.

Reproducible: Always

Steps to Reproduce:
Reproduction requires a plugin which has NPP_WriteReady returning zero to throttle a stream unfortunately.  Sorry.
Actual Results:  
A URL for a stream ends up bugged until you clear browser cache or restart the browser

Expected Results:  
URL should work the next time you use it, even when it was throttled in the previous plugin instance.

Comment 1

11 years ago
I am working around the same (or similar) bug. I just haven't had a chance to raise it yet.
The problem also appears in Firefox 1.5, 2.0.0.6 and the nightly build for 3.0.

I have found a workaround for the problem, but it breaks the documented contract for NPP_Write(). See below:

NPP_WriteReady()
{
    if (cannot accept more data)
    {
        m_canAcceptData = false;
        return 1;
    }
    else
    {
        m_canAcceptData = true;
        return numberOfBytesToAccept;
    }
}


NPP_Write()
{
    if (m_canAcceptData == false)
    {
        return 0;
    }

    // Do normal work here.
}


This appears to work for all my tests so far.
(Reporter)

Comment 2

11 years ago
Interesting. I had my hopes up but this workaround hasn't worked for me so far.  This is in Firefox 2.0.0.9. If I return 0 from NPP_Write instead of throttling the stream with NPP_WriteReady I get the same result.  If NPP_Destroy or NPP_DestroyStream is called while NPP_Write is returning 0 on the stream the URL will be hung until the browser cache is cleared or you restart the browser.  This is a secondary stream where the URL request was initiated by the plugin and not the root stream loading the base plugin content.

Comment 3

11 years ago
Sorry. I have since realised that my problem is slightly different, but I had hoped that it might work here as well.
FYI my issue is caused by the browser stopping all callbacks after zero is repeatedly returned from NPP_WriteReady().
I will have to raise my own bug.
(Reporter)

Comment 4

11 years ago
I think this has been fixed/workaround on the plugin side.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.