It definitely shouldn't happen for <audio>/<video>. That's clearly specified. There's nothing special about being inserted into a document, whether it's the owner doc or not. Firefox and Safari do this right. Chrome has a bug with it:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2755

With images, if the resolved URL is different, Firefox does load the image afresh:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2758 (same)
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2759 (different)

Chrome and Safari reload the image even if the URL resolves unchanged.

Anyone got IE around to test?

Firefox actually does this when you insert the node into the other document, not when you change the ownerDocument. Chrome does it when you change the ownerDocument. Which do we want to do, if either?

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2765

Firefox generally reloads images on insert into DOM if the image URI has changed in the process, since we support xml:base.

If xml:base support goes away, then doing it on adopt makes some sense...

Adam, do you have an opinion on when you want <img> to re-load? Adoption? Insertion after adoption?

(In reply to Ian 'Hixie' Hickson from comment #5)
> Adam, do you have an opinion on when you want <img> to re-load? Adoption?
> Insertion after adoption?

Adoption would be consistent with existing WebKit and Blink behavior, so I guess that's my default preference.

What happens in the insert-into-other-document case (which auto-adopts).  Should the load happen after the adopt but before the insert in that case, or after the insert?

We can obviously add a special case to load if the URI changed on adopt in Gecko.  I would prefer to not force a load if the URI has not changed.

(In reply to Boris Zbarsky from comment #7)
> What happens in the insert-into-other-document case (which auto-adopts). 
> Should the load happen after the adopt but before the insert in that case,
> or after the insert?

Since Blink doesn't support xml:base for <img>, this doesn't matter for us (unless I'm missing something).

> We can obviously add a special case to load if the URI changed on adopt in
> Gecko.  I would prefer to not force a load if the URI has not changed.

We should probably have such a special case in Blink if we don't already.

> this doesn't matter for us (unless I'm missing something).

It matters once the load depends on contextual information (c.f. <picture>).  It also matters depending on the outcome of the discussion in bug 20976.

> It matters once the load depends on contextual information (c.f. <picture>).
> It also matters depending on the outcome of the discussion in bug 20976.

Good points. At the moment, adoption happens before insertion, and so loading is triggered before insertion as well. If we wanted to change that it should be doable, though (given, as I noted before, that there aren't any web compat issues for us).

See also this active thread on blink-dev: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hKj2OsvZl1g

As for <picture>, I think it makes sense to rerun the selection algorithm when an <img> is moved to a different document. (This seems separate from the question about whether to re-resolve the URLs and whether to reload if the resulting URL is the same.)

So what's our conclusion here? Would this work?:

 - on a straight adoption, reresolve the URL, and if it changed, reload
 - on an adoption that is part of an insertion, wait until the insertion is done,
   and then reresolve and, if it changed, reload
 - on all other base URL changes, do nothing

Anne, what did we decide about when the adopt handlers from insert-and-adopt run?  Seems like fundamentally we should do this from those, like other base URI fixup...

Agreed. So once we have the custom elements machinery working, timing-wise this adopt-callback would run just before the method that caused the adopt to happen returns. HTML would then plug base URL fixup on it and reloading for various elements.

For now I'll run the adopt steps synchronously awaiting some kind of mechanism to make them run a tad later.

So you're saying there'll be a hook for HTML to use?

http://dom.spec.whatwg.org/#concept-node-adopt-ext is the callback hook. What I'm saying is that currently it runs sync, but once custom element integration has been improved it will run slightly later.

Will it run after insertion in the case of an adoption that happens as part of insertion into a subtree with a different owner document?

Yes, it would run after the insertion. E.g. if you do appendChild() it would run just before that method returns. 

(I wish the custom element had talked to you about what they are doing so I don't have to do all their coordination work :/)

(In reply to Anne from comment #19)
> Yes, it would run after the insertion. E.g. if you do appendChild() it would
> run just before that method returns. 
> 
> (I wish the custom element had talked to you about what they are doing so I
> don't have to do all their coordination work :/)

Here's a quick catch-up/recap:

We're adding adopt node callback to custom elements (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24577). The timing of when this callback is invoked will be shifted relative to when it is enqueued, as Anne indicated early.

The reason for the timing change is fulfilling UAs wish not to allow author code to run in the middle of its work. This is why custom elements have the element/callback queues (http://w3c.github.io/webcomponents/spec/custom/#enqueuing-and-invoking-callbacks).

So yes, the timing of the callback may depend on whether the callback is trusted by the UA (in which case it is invoked right away) or not (in which case it is invoked at the time that UA considers it safe).

As an aside, this time-shifting plumbing should probably be made into its own primitive (a write barrier of sorts), which would enable UAs to arbitrarily erect this barrier to protect integrity of certain DOM operations (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24655)

Ok, I don't really see why custom elements are relevant here then.

As far as I can tell, the bug here is just that <img> should reevaluate itself when #concept-node-adopt-ext is invoked.

(In reply to Ian 'Hixie' Hickson from comment #21)
> Ok, I don't really see why custom elements are relevant here then.
> 
> As far as I can tell, the bug here is just that <img> should reevaluate
> itself when #concept-node-adopt-ext is invoked.

Sounds about right.

Checked in as WHATWG revision r8509.
Check-in comment: Make <img> reload if inserting it into a new doc causes the URL to change (note that exactly what this does depends on whether the browser's 'list of available images' is maintained per-Doc, or whether there's only one list per origin)
http://html5.org/tools/web-apps-tracker?from=8508&to=8509