Olli Pettay [:smaug][bugs@pettay.fi] Assignee
	Description • 16 years ago

Occasionally when creating lots of XMLHttpRequest objects, so that some of them
have to wait others to finish, OnProgress seems to get called with
parameters where aProgress > aProgressMax.
aProgressMax does have the right value (size of headers + size of content), so
it is aProgress which is wrong.
I used this http://mozilla.pettay.fi/xhr_upload/xhr_upload_demo_test.html
to test. It dumps info to console if something goes wrong. Just create 5 XHRs, and
press the button few times.
I verified the problem with some printfs in XHR ::OnProgress.

	Olli Pettay [:smaug][bugs@pettay.fi] Assignee
	Comment 2 • 16 years ago

It seems that nsSocketOutputStream::Write increases mByteCount too much.
mByteCount gets increased up to twice too much?
I'm very unfamiliar with necko code, still trying to find why that happens
and if mByteCount should be reseted somwhere or if nsSocketOutputStream::Write is 
called too often...
XHR uploads the right data, so aProgress doesn't reflect the actually amount
of sent data.

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 16 years ago

nsSocketOutputStream::Write increases mByteCount by the number it returns for bytes written: the return value of PR_Write.  That seems correct, no?

	Olli Pettay [:smaug][bugs@pettay.fi] Assignee
	Comment 4 • 16 years ago

Or perhaps some extra data is sent, but content-length has still the original value. /me continues debugging.

	Olli Pettay [:smaug][bugs@pettay.fi] Assignee
	Comment 5 • 16 years ago

Finally found the problem, sort for. It is in nsHttpConnection::Activate, which 
doesn't recreate SocketTransport if there is one already. And that causes
mSocketOut to be reused, but without re-initializing it in any way.
Will try to come up with a patch (first ever in necko).

	Olli Pettay [:smaug][bugs@pettay.fi] Assignee
	Comment 6 • 16 years ago

And for download aProgress is right because it is synthesized in nsHttpChannel::OnDataAvailable

	Olli Pettay [:smaug][bugs@pettay.fi] Assignee
	Comment 7 • 16 years ago

So far I haven't found any better option, but as I said, I'm not familiar with this code.

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 8 • 16 years ago

I don't really like messing with the socket transport like that. Can you handle this in the HTTP code instead?

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 10 • 16 years ago

Comment on attachment 335886 [details] [diff] [review]
update progress value in http code

+        nsCOMPtr<nsISeekableStream> seekable = do_QueryInterface(mRequestStream);
+        if (!seekable) {

I don't see how this QI can fail. Can you replace the if with an assertion?