img.complete behavior is wrong when a new load is started for the same image

[bzbarsky]

Consider this testcase:

  var img = new Image();
  img.src = "url1";
  img.onload = () => {
    img.src = "url2"; // Make sure this is not in the document's loaded-images cache
    alert(img.complete);
  }

Per spec at https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-complete this should alert true because:

• First bullet does not apply, because there is an src attribute
• Second bullet does not apply, because src is nonempty
• Third bullet, who knows
• Fourth bullet applies (!) because there is a current request and its status is completely available.

Presumably complete should returns false if there is a pending request or something? It consistently returns false in browsers on the above testcase.

@EdgarChen @annevk @domenic

[bzbarsky]

Once this is fixed, the comment in the img.complete.html WPT referencing this issue should be removed.

[EdgarChen]

Presumably complete should returns false if there is a pending request or something? It consistently returns false in browsers on the above testcase.

Checking pending request seems not help here, nor does #4476, given that the steps after step 7 of update-image-data is async per spec?

Current Gecko returns false is because we run update-image-data in a sync way for non-responsive case in Gekco implementation. I suspect other browsers also run update-image-data in a sync way for this case.

Another interesting example,

var img = new Image();
  img.srcset = "url1";
  img.onload = () => {
    img.srcset = "url2"; // Make sure this is not in the document's loaded-images cache
    alert(img.complete);
  }

Gecko returns true in this example, it is because we do follow spec that run update-image-data in an async way for responsive case. However, other browsers still return false, It looks like that other browsers still run update-image-data in a sync way even for responsive case?

[bzbarsky]

At least in Chrome, .complete returns false if the "update the image data" task is queued at all (and they queue it in all sorts of cases when they should not; see https://bugs.chromium.org/p/chromium/issues/detail?id=1000273).

It would make some sense to return false for .complete if we have reached step 7 of the update the image data steps, I suspect... as long as we don't do it in the cases that would return early in step 10 and maybe step 11? Unclear.

[bzbarsky]

This seems like a duplicate of #4475.

That claims to be resolved by #4934 but this issue is still unresolved, as far as I can tell. See #4934 (comment)

@jdm

[annevk]

I think I see now, the problem is that https://html.spec.whatwg.org/#update-the-image-data does not update any state on the image element synchronously when an asynchronous fetch is to be performed and therefore complete might still return the wrong value as it only uses such state.

I think this is related to some other problems with the img element about it being unclear whether it should use "await a stable state". Parsing that URL that late is also somewhat problematic from a blob URL perspective, for instance. (#2429 as @EdgarChen referenced already.)