Update MediaSource to allow append() calls in "ended" state.
https://bugs.webkit.org/show_bug.cgi?id=104581

Reviewed by Eric Carlson.

Source/WebCore:

Updated append and setTimestampOffset to allow appending in the "ended" readyState. An append() call
in the "ended" state now triggers a transition to the "open" state and allows the append to succeed.

Tests: http/tests/media/media-source/video-media-source-append-in-ended-state.html
       http/tests/media/media-source/video-media-source-append-with-offset-in-ended-state.html
       http/tests/media/media-source/video-media-source-zero-byte-append-in-ended-state.html

* Modules/mediasource/MediaSource.cpp:
(WebCore::MediaSource::append):
(WebCore::MediaSource::setTimestampOffset):

LayoutTests:

- Removed old test case that verified appending in "ended" state failed.
- Added 3 new test cases that verify append behavior in the "ended" state.

* http/tests/media/media-source/video-media-source-add-and-remove-buffers-expected.txt:
* http/tests/media/media-source/video-media-source-add-and-remove-buffers.html:
* http/tests/media/media-source/video-media-source-append-in-ended-state-expected.txt: Added.
* http/tests/media/media-source/video-media-source-append-in-ended-state.html: Added.
* http/tests/media/media-source/video-media-source-append-with-offset-in-ended-state-expected.txt: Added.
* http/tests/media/media-source/video-media-source-append-with-offset-in-ended-state.html: Added.
* http/tests/media/media-source/video-media-source-zero-byte-append-in-ended-state-expected.txt: Added.
* http/tests/media/media-source/video-media-source-zero-byte-append-in-ended-state.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137332 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Route main resource loads through the memory cache.
https://bugs.webkit.org/show_bug.cgi?id=49246

Reviewed by Antti Koivisto.

Source/WebCore:

Note that this patch doesn't actually enable caching of main resources. That will be done in a later patch.
The MainResourceLoader actually has an underlying SubresourceLoader (with the cache layer between them).
In several places, the MainResourceLoader's SubresourceLoader is treated as special.

No new tests, as this is primarily a refactor. A couple of expected results changed slightly.

* loader/DocumentLoader.cpp:
(WebCore::DocumentLoader::setRequest):
(WebCore::DocumentLoader::subresource):
(WebCore::DocumentLoader::addSubresourceLoader): Because the SubresourceLoader underlying the main resource
    needs special handling in certain cases, track it separately from the real SubresourceLoaders.
(WebCore::DocumentLoader::removeSubresourceLoader):
(WebCore::DocumentLoader::startLoadingMainResource):
* loader/MainResourceLoader.cpp:
(WebCore::MainResourceLoader::MainResourceLoader):
(WebCore::MainResourceLoader::receivedError):
(WebCore::MainResourceLoader::cancel):
(WebCore::MainResourceLoader::clearResource):
(WebCore):
(WebCore::MainResourceLoader::frameLoader):
(WebCore::MainResourceLoader::request):
(WebCore::MainResourceLoader::continueAfterNavigationPolicy):
(WebCore::MainResourceLoader::resourceData):
(WebCore::MainResourceLoader::redirectReceived):
(WebCore::MainResourceLoader::willSendRequest):
(WebCore::MainResourceLoader::continueAfterContentPolicy):
(WebCore::MainResourceLoader::responseReceived):
(WebCore::MainResourceLoader::dataReceived):
(WebCore::MainResourceLoader::didFinishLoading):
(WebCore::MainResourceLoader::notifyFinished):
(WebCore::MainResourceLoader::reportMemoryUsage):
(WebCore::MainResourceLoader::handleSubstituteDataLoadNow):
(WebCore::MainResourceLoader::load):
(WebCore::MainResourceLoader::setDefersLoading):
(WebCore::MainResourceLoader::defersLoading):
(WebCore::MainResourceLoader::setShouldBufferData):
(WebCore::MainResourceLoader::loader):
(WebCore::MainResourceLoader::identifier):
* loader/MainResourceLoader.h:
(MainResourceLoader):
(WebCore::MainResourceLoader::documentLoader):
* loader/ResourceLoader.cpp:
(WebCore::ResourceLoader::willSendRequest):
* loader/ResourceLoader.h:
(WebCore::ResourceLoader::defersLoading):
(WebCore::ResourceLoader::cancelled):
* loader/appcache/ApplicationCacheHost.cpp:
(WebCore::ApplicationCacheHost::maybeLoadFallbackForMainResponse):
(WebCore::ApplicationCacheHost::maybeLoadFallbackForMainError):
* loader/mac/DocumentLoaderMac.cpp:
(WebCore::DocumentLoader::schedule):
(WebCore::DocumentLoader::unschedule):

LayoutTests:

* http/tests/inspector/resource-parameters.html: The main resource's url will exclude the fragment identifier here.
* http/tests/misc/will-send-request-returns-null-on-redirect-expected.txt: The error code for loads cancelled
    by an embedder's willSendRequest() will show as standard load cancellations rather than as a content policy
    failure. This was an odd quirk of how MainResourceLoader::willSendRequest() was implemented (namely, doing a
    content policy check on ResourceRequests with empty urls).
* platform/chromium/http/tests/misc/will-send-request-returns-null-on-redirect-expected.txt: See previous.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137333 268f45cc-cd09-0410-ab3c-d52691b4dbfc