When the GPU Process' MediaPlayerProxy needs to allocate a new MediaResource it sends a message to the content process via the MediaPlayerPrivateRemote::RequestResource IPC call with a RemoteMediaResourceIdentifier which will then respond with that same RemoteMediaResourceIdentifier to indicate that the MediaResource is now "ready".

There's two scenarios possible here.
Either the creation of the media resource in the content process is successful or it's not.

If it's successful the content process will start sending data starting by a call to the GPU's RemoteMediaResourceManager responseReceived
Or it will fail and call RemoteMediaResourceManager::LoadFailed.

The RemoteMediaResourceManager will only accept incoming data once the MediaResource's ready status is true, and if you're only working on the main thread, it will always be, as the Content Process' RequestResource response will always be received before either LoadFailed or ResponseReceived call.

So if only working on the main thread as we do now, this ready status is totally redundant.

However, if we want to parallelise networking operations so that ResponseReceived and LoadFailed will be called on a secondary thread as introduced in bug 235353; the "ready" flag becomes problematic as the response from a RequestResource is happening on the main thread.
The multi-threaded nature of the work means that the RequestResource response could be received only after LoadFailed or ResponseReceived message; and if that's the case those two messages will be dropped.

This can be seen with the intermittent failures occurring with media/video-src-blob-replay.html test.

So we will remove this concept of RemoteMediaResource::ready as at best it serves no purpose.