Bug 1374591 - Use the correct progressMax in nsHttpChannel::OnDataAvailable for alt-data content r=michal
MozReview-Commit-ID: KUJXHwkooHE
--- a/netwerk/protocol/http/nsHttpChannel.cpp
+++ b/netwerk/protocol/http/nsHttpChannel.cpp
@@ -7434,16 +7434,17 @@ private:
int64_t mProgressMax;
};
NS_IMETHODIMP
nsHttpChannel::OnDataAvailable(nsIRequest *request, nsISupports *ctxt,
nsIInputStream *input,
uint64_t offset, uint32_t count)
{
+ nsresult rv;
PROFILER_LABEL("nsHttpChannel", "OnDataAvailable",
js::ProfileEntry::Category::NETWORK);
LOG(("nsHttpChannel::OnDataAvailable [this=%p request=%p offset=%" PRIu64
" count=%" PRIu32 "]\n",
this, request, offset, count));
LOG((" requestFromCache: %d mFirstResponseSource: %d\n",
@@ -7478,17 +7479,21 @@ nsHttpChannel::OnDataAvailable(nsIReques
else
transportStatus = NS_NET_STATUS_RECEIVING_FROM;
// mResponseHead may reference new or cached headers, but either way it
// holds our best estimate of the total content length. Even in the case
// of a byte range request, the content length stored in the cached
// response headers is what we want to use here.
- int64_t progressMax(mResponseHead->ContentLength());
+ int64_t progressMax = -1;
+ rv = GetContentLength(&progressMax);
+ if (NS_FAILED(rv)) {
+ NS_WARNING("GetContentLength failed");
+ }
int64_t progress = mLogicalOffset + count;
if ((progress > progressMax) && (progressMax != -1)) {
NS_WARNING("unexpected progress values - "
"is server exceeding content length?");
}
// make sure params are in range for js
@@ -7498,17 +7503,17 @@ nsHttpChannel::OnDataAvailable(nsIReques
if (!InScriptableRange(progress)) {
progress = -1;
}
if (NS_IsMainThread()) {
OnTransportStatus(nullptr, transportStatus, progress, progressMax);
} else {
- nsresult rv = NS_DispatchToMainThread(
+ rv = NS_DispatchToMainThread(
new OnTransportStatusAsyncEvent(this, transportStatus,
progress, progressMax));
NS_ENSURE_SUCCESS(rv, rv);
}
//
// we have to manually keep the logical offset of the stream up-to-date.
// we cannot depend solely on the offset provided, since we may have