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:

  https://searchfox.org/mozilla-central/rev/ac142717cc067d875e83e4b1316f004f6e063a46/dom/base/nsNoDataProtocolContentPolicy.cpp#59

This ensures we treat these two cases the same.

Differential Revision: https://phabricator.services.mozilla.com/D89382

dom/base/nsImageLoadingContent.cpp

@@ -1211,7 +1211,10 @@ 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;
+      mImageBlockingStatus = nsIContentPolicy::REJECT_REQUEST;
+    }
 
     FireEvent(u"error"_ns);
     FireEvent(u"loadend"_ns);

layout/reftests/image/reftest.list

@@ -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

layout/reftests/image/unknown-protocol-ref.html

@@ -0,0 +1 @@
+<img src="mailto://foo">

layout/reftests/image/unknown-protocol.html

@@ -0,0 +1 @@
+<img src="foobar://baz">