Commit 131f3d27 authored by Emilio Cobos Álvarez's avatar Emilio Cobos Álvarez Committed by Matthew Finkel
Browse files

Bug 1658881 - When failing to create a channel and an image request, make sure...

Bug 1658881 - When failing to create a channel and an image request, make sure to set the image blocking status appropriately. r=tnikkel

This is the same status as we do for known no-data protocols here:

This ensures we treat these two cases the same.

Differential Revision:
parent 88ef1ab5
......@@ -1207,7 +1207,12 @@ nsresult nsImageLoadingContent::LoadImage(nsIURI* aNewURI, bool aForce,
MOZ_ASSERT(!req, "Shouldn't have non-null request here");
// If we don't have a current URI, we might as well store this URI so people
// know what we tried (and failed) to load.
if (!mCurrentRequest) mCurrentURI = aNewURI;
if (!mCurrentRequest) {
mCurrentURI = aNewURI;
if (mImageBlockingStatus == nsIContentPolicy::ACCEPT) {
mImageBlockingStatus = nsIContentPolicy::REJECT_REQUEST;
......@@ -69,3 +69,4 @@ random-if(/^Windows\x20NT\x206\.1/.test(http.oscpu)) == image-srcset-basic-selec
pref(dom.image-lazy-loading.enabled,true) == moz-broken-matching-lazy-load.html moz-broken-matching-1-ref.html
== img-invalidation-local-transform-1.html img-invalidation-local-transform-1-ref.html
== unknown-protocol.html unknown-protocol-ref.html
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment