The Decode call may result in synchronously creating the surface, but we only check again if the surface is there for FLAG_SYNC_DECODE, not FLAG_SYNC_DECODE_IF_FAST. All of the decoding we do during painting is of the type FLAG_SYNC_DECODE_IF_FAST, which means it would be useful to do that decoding synchronously during painting because the paint doesn't benefit from the result of that decoding. Looking at the history of this code it looks like https://hg.mozilla.org/mozilla-central/rev/435df926eb10 (part 6 of bug 1119774) was where this bug was introduced. Before that changeset we always did another LookupFrameInternal call after the Decode (call WantDecodedFrames back then). But that changeset changed it to only be done for standard sync decodes, not "sync decode if fast". Found this while investigating try server orange for bug 1317562.

Pushed by tnikkel@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b50b2a2b2b6f RasterImage::LookupFrame does not return a surface if it was created as a result of a sync decode from with the FLAG_SYNC_DECODE_IF_FAST flag. r=aosmond