With the following code, if the resource file does not exist on disk then the first call to stream->Read() will block forever. It should return an error code either in this call, or one of the earlier calls. // Open stream to read top sites resource file nsIURL* url; nsresult rv = NS_NewURL(&url, "resource:/res/topsites.txt"); if (rv != NS_OK) { return; } nsIInputStream* stream; rv = NS_OpenURL(url, &stream); if (rv != NS_OK) { NS_RELEASE(url); return; } PRUint32 len; char buf[1024]; nsString sitesStr; // Load file into buffer do { // >>>> THIS LINE IS BLOCKING FOREVER <<<< rv = stream->Read(buf, 0, 1024, &len); if (rv != NS_OK) break; sitesStr.Append(buf, len); } while (len > 0); NS_RELEASE(url); NS_RELEASE(stream);

Thanks Michael.

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

Error case. Wait for netlib rewrite to fix it.

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Please check with Necko.

Michael, are you around? Can you verify that this is fixed with the new networking library?

The symptoms of this bug appear to be fixed (ie. it no longer seems to block loading a non-existant resource file), but I don't have the time right now to check the specific code example given in the original bug report.

thanks, I will mark verified and you may re-open in future if you run into it again

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.