Currently, we don't let nsImageLoadingContent block onload for non-current requests. Unfortunately, this leads to problems when we want to change the precise ordering of events, leading to either onload not being blocked (assertions) or being blocked permanently. By making nsImageLoadingContent handle [Un]BlockOnload on the pending request, we can fix some of these issues.

I need more detail to understand the motivation here. What problems are you having? What events are you reordering?

Currently, BlockOnload happens directly from decoders when they are initialized (OnStartDecode is called from Decoder::Init). In a post-bug 716140 world, decoders *never* call callbacks directly; instead, those callbacks are recorded and then replayed asynchronously. Unfortunately, this means that we have to make a static decision about when to call these event callbacks. In particular, current mozilla-central calls OnStopRequest before calling BlockOnload (but without going back to the event queue, so usually it doesn't cause any confusion). We can make no such guarantees. mCurrentRequest is only updated from nsImageLoadingContent::OnStopRequest, which means that if we call BlockOnload before OnStopRequest, the current implementation of BlockOnload will simply ignore the calls and we get assertions when UnblockOnload() is called. If we delay BlockOnload until after OnStopRequest, we get into a similar but opposite situation with UnblockOnload, IIRC. The most bulletproof way to solve this problem which doesn't depend on event ordering at all w.r.t. the current and pending request is to block onload regardless of whether we're the current request.

Comment on attachment 724159 [details] [diff] [review] allow pending request from [un]block r=me This should also fix Bug 787037 which happens when a BlockOnload is called when the request is still pending but UnblockOnload is called when it finishes.