Bug 1411473 - Skip image loading from adoption if OwnerDoc is not allowed to. r=bz

In the test file 1411473.html, there are 3 calls to
nsImageLoadingContent::LoadImage

1. Triggered by setting src attribute, and this sets the mCurrentRequest.

2. Triggered by setting crossOrigin attribute, this forcibly reloads the image,
and this sets the mPendingRequest.

3. Triggered by loading the image which is adopted into a new created data
document by
'document.implementation.createDocument('', '', null).adoptNode(img)'

However in the 3rd call, when it calls nsImageLoadingContent::LoadImage, It
will bail out in the aDocument->IsLoadedAsData() part
http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/dom/base/nsImageLoadingContent.cpp#942

And when it calls SetBlockedRequest, at this time we have a non-null
mCurrentRequest and a non-null mPendingRequest, so this triggers the
assertion of mPendingRequest should be null when we got blocked, which
is added in bug 1267075.

Since data document is not the active document,
per https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data,
Step 1, we should skip the image loading in HTMLImageElement.

dom/html/HTMLImageElement.cpp

@@ -700,7 +700,7 @@ HTMLImageElement::NodeInfoChanged(nsIDocument* aOldDoc)
   // Force reload image if adoption steps are run.
   // If loading is temporarily disabled, don't even launch script runner.
   // Otherwise script runner may run later when someone has reenabled loading.
-  if (LoadingEnabled()) {
+  if (LoadingEnabled() && OwnerDoc()->ShouldLoadImages()) {
     // Use script runner for the case the adopt is from appendChild.
     // Bug 1076583 - We still behave synchronously in the non-responsive case
     nsContentUtils::AddScriptRunner(