(In reply to Jonathan Kew (:jfkthame) from comment #0)
> Maybe a regression from one of the GLContext-related patches in that range?
Wrong guess; the regression actually comes from bug 693183 (changeset dfa418ec22f1). Moving to SVG.

The reftest-analyzer uses display:none images. Moving the image attribute processing to occur in frames means that display:none images don't really work so well now. Perhaps reftest-analyzer could use visibility:hidden instead?

SVG is supposed to work in a display:none context but firefox basically doesn't and never has properly. bug 376027 tracks that. Animation of any attribute e.g. the image x, y, width and height requires a frame for instance.
We could put the AfterSetAttr call back in the nsSVGImageElement and check in there whether the image has a frame, if there is return in that method as the frame will handle things and if there isn't then do what happened before. That will make this case work.

Moving _loading_ of the image into the frame is just broken. Why was that done, exactly? Why can't you just move that whole xlink:href block back into the content class and take it out of the frame completely?

(In reply to Boris Zbarsky (:bz) from comment #7)
> Moving _loading_ of the image into the frame is just broken. Why was that
> done, exactly? Why can't you just move that whole xlink:href block back
> into the content class and take it out of the frame completely?
All our SMIL animation works off frames. If we have it in content then we need special overrides for frames which I'm trying to get rid of.

And in particular, unlike the other attributes that were moved, which affect just the rendering, the loading business affects all sorts of things that have nothing to do with frames. The result of that change is that setting the xlink:href attribute on an image may now work or not pretty randomly depending on timing and what other DOM changes are going on, without even involving display:none. For example, this testcase:
<body>
<svg></svg>
<script>
var img = document.createElementNS("http://www.w3.org/2000/svg", "image");
img.setAttribute("width", "100");
img.setAttribute("height", "100");
document.querySelector("svg").appendChild(img);
img.setAttributeNS("http://www.w3.org/1999/xlink", "xlink:href", "test.png");
</script>
</body>
doesn't show the image in a current nightly. But if I reorder the last two lines of the script, or add a style flush right before the setAttributeNS call or any of a variety of other changes (e.g. put the <svg> inside a contenteditable div) that affect the exact timing of frame construction it will suddenly start working.
As I said, broken. We need to fix this.

(In reply to Boris Zbarsky (:bz) from comment #14)
> And maybe that just means we need to fix SMIL...
>
> Does SMIL invoke the AttributeChanged method of the frame without actually
> changing the attribute on the content or something?
It does.

(In reply to Boris Zbarsky (:bz) from comment #16)
> Is there a reason it could not call BeforeSetAttr/AfterSetAttr on the
> content? Would that eliminate the frame dependency? Or does it need frames
> for basic functioning (e.g. getting style data)?
Style data is the main issue I think.

Hi, just as a matter of interest, what is the !IsCallerChrome() for in:
nsContentUtils::IsImageSrcSetDisabled()
return Preferences::GetBool("dom.disable_image_src_set") && !IsCallerChrome();
}
We're getting a crash from IsCallerChrome(), see bug 1219253 comment #12.