nephele
/
haikuwebkit
1
0
Fork 0
Code Issues Releases Activity
haikuwebkit/LayoutTests/loader/go-back-cached-main-resourc...

26 lines
2.0 KiB
Plaintext
Raw Permalink Normal View History

FrameLoaderClient::assignIdentifierToInitialRequest() not called for the main resource when loaded from the memory cache https://bugs.webkit.org/show_bug.cgi?id=112418 Source/WebCore: Reviewed by Darin Adler. When the main resource is loaded from the memory cache the response is not added to the ResponseVector of the document loader, so that when committing the provisional load the remaining delegate messages are not called because the ResponseVector of the document loader is empty. When the main resource is loaded from the memory cache, there's no resource loader, and the client is notified about the response received using ResourceLoadNotifier::dispatchDidReceiveResponse() directly instead of ResourceLoadNotifier::didReceiveResponse() which is the one adding the response to the ResponseVector of the document loader. So, the problem can be fixed by adding the response to the ResponseVector before calling dispatchDidReceiveResponse() when loading the main resource without a resource loade Test: loader/go-back-cached-main-resource.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::responseReceived): LayoutTests: Patch by Manuel Rego Casasnovas <rego@igalia.com> on 2013-04-11 Reviewed by Darin Adler. * loader/go-back-cached-main-resource-expected.txt: Added. * loader/go-back-cached-main-resource.html: Added. * loader/resources/first-page.html: Added. * loader/resources/other-page.html: Added. * platform/gtk-wk1/loader/go-back-cached-main-resource-expected.txt: Added. * platform/wk2/loader/go-back-cached-main-resource-expected.txt: Added. Canonical link: https://commits.webkit.org/132797@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@148182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-04-11 08:25:51 +00:00
resources/first-page.html - willSendRequest <NSURLRequest URL resources/first-page.html, main document URL resources/first-page.html, http method GET> redirectResponse (null)
<unknown> is often dumped instead of path in test output https://bugs.webkit.org/show_bug.cgi?id=119590 Reviewed by Anders Carlsson. Tools: There were two reasons for <unknown>: 1. When delegate logging is enabled via a testRunner call, that obviously happens after main resource load starts, so we don't record its URL. 2. Authentication delegate logging relied on URL recording, but it's only turned on when enabling resource loading delegate logging, not auth one. URL recording was made conditional in <http://trac.webkit.org/r19316>, which was landed without posted rationale and unreviewed. Just undoing that change now. * DumpRenderTree/mac/ResourceLoadDelegate.mm: (-[ResourceLoadDelegate webView:identifierForInitialRequest:fromDataSource:]): * WebKitTestRunner/InjectedBundle/InjectedBundlePage.cpp: (WTR::InjectedBundlePage::didInitiateLoadForResource): LayoutTests: Updating test results. * fast/loader/file-protocol-fragment-expected.txt: * fast/loader/main-document-url-for-non-http-loads-expected.txt: * http/tests/cache/iframe-304-crash-expected.txt: * http/tests/cache/willsendrequest-returns-null-for-memory-cache-load-expected.txt: * http/tests/loading/307-after-303-after-post-expected.txt: * http/tests/loading/authentication-after-redirect-stores-wrong-credentials/authentication-after-redirect-stores-wrong-credentials-expected.txt: * http/tests/loading/basic-auth-resend-wrong-credentials-expected.txt: * http/tests/loading/basic-credentials-sent-automatically-expected.txt: * http/tests/loading/redirect-methods-expected.txt: * http/tests/misc/401-alternative-content-expected.txt: * http/tests/misc/authentication-redirect-1/authentication-sent-to-redirect-cross-origin-expected.txt: * http/tests/misc/authentication-redirect-2/authentication-sent-to-redirect-same-origin-expected.txt: * http/tests/misc/authentication-redirect-4/authentication-sent-to-redirect-same-origin-url-expected.txt: * http/tests/misc/favicon-loads-with-images-disabled-expected.txt: * http/tests/misc/link-rel-icon-beforeload-expected.txt: * http/tests/misc/will-send-request-returns-null-on-redirect-expected.txt: * http/tests/misc/window-dot-stop-expected.txt: * http/tests/security/401-logout/401-logout-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-allowall-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-deny-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-in-body-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-allow-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-deny-meta-tag-parent-same-origin-deny-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-invalid-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-multiple-headers-conflict-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-allow-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-multiple-headers-sameorigin-deny-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-allow-expected.txt: * http/tests/security/XFrameOptions/x-frame-options-parent-same-origin-deny-expected.txt: * http/tests/xmlhttprequest/failed-auth-expected.txt: * http/tests/xmlhttprequest/remember-bad-password-expected.txt: * loader/go-back-cached-main-resource-expected.txt: * platform/efl-wk2/loader/go-back-cached-main-resource-expected.txt: * platform/mac/fast/images/support-broken-image-delegate-expected.txt: * platform/mac/security/block-test-expected.txt: * platform/mac/security/block-test-no-port-expected.txt: * platform/mac/webarchive/loading/cache-expired-subresource-expected.txt: * webarchive/loading/test-loading-archive-expected.txt: * webarchive/loading/test-loading-archive-subresource-null-mimetype-expected.txt: Canonical link: https://commits.webkit.org/137597@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153903 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-08-09 18:40:48 +00:00
go-back-cached-main-resource.html - didFinishLoading
FrameLoaderClient::assignIdentifierToInitialRequest() not called for the main resource when loaded from the memory cache https://bugs.webkit.org/show_bug.cgi?id=112418 Source/WebCore: Reviewed by Darin Adler. When the main resource is loaded from the memory cache the response is not added to the ResponseVector of the document loader, so that when committing the provisional load the remaining delegate messages are not called because the ResponseVector of the document loader is empty. When the main resource is loaded from the memory cache, there's no resource loader, and the client is notified about the response received using ResourceLoadNotifier::dispatchDidReceiveResponse() directly instead of ResourceLoadNotifier::didReceiveResponse() which is the one adding the response to the ResponseVector of the document loader. So, the problem can be fixed by adding the response to the ResponseVector before calling dispatchDidReceiveResponse() when loading the main resource without a resource loade Test: loader/go-back-cached-main-resource.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::responseReceived): LayoutTests: Patch by Manuel Rego Casasnovas <rego@igalia.com> on 2013-04-11 Reviewed by Darin Adler. * loader/go-back-cached-main-resource-expected.txt: Added. * loader/go-back-cached-main-resource.html: Added. * loader/resources/first-page.html: Added. * loader/resources/other-page.html: Added. * platform/gtk-wk1/loader/go-back-cached-main-resource-expected.txt: Added. * platform/wk2/loader/go-back-cached-main-resource-expected.txt: Added. Canonical link: https://commits.webkit.org/132797@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@148182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-04-11 08:25:51 +00:00
resources/first-page.html - didReceiveResponse <NSURLResponse resources/first-page.html, http status code 0>
resources/first-page.html - didFinishLoading
resources/other-page.html - willSendRequest <NSURLRequest URL resources/other-page.html, main document URL resources/other-page.html, http method GET> redirectResponse (null)
resources/other-page.html - didReceiveResponse <NSURLResponse resources/other-page.html, http status code 0>
resources/other-page.html - didFinishLoading
resources/first-page.html - willSendRequest <NSURLRequest URL resources/first-page.html, main document URL resources/first-page.html, http method GET> redirectResponse (null)
resources/first-page.html - didReceiveResponse <NSURLResponse resources/first-page.html, http status code 0>
resources/first-page.html - didFinishLoading
resources/other-page.html - willSendRequest <NSURLRequest URL resources/other-page.html, main document URL resources/other-page.html, http method GET> redirectResponse (null)
resources/other-page.html - didReceiveResponse <NSURLResponse resources/other-page.html, http status code 0>
resources/other-page.html - didFinishLoading
Inconsistencies in main resource load delegates when loading from history https://bugs.webkit.org/show_bug.cgi?id=150927 Reviewed by Michael Catanzaro. Source/WebCore: When restoring a page from the page cache, even though there isn't an actual load of resources, we are still emitting the load delegates to let the API layer know there are contents being loaded in the web view. This makes the page cache restoring transparent for the API layer. However, when restoring a page from the cache, all the delegates are emitted after the load is committed. This is not consistent with real loads, where we first load the main resource and once we get a response we commit the load. This inconsistency is problematic if the API layer expects to always have a main resource with a response when the load is committed. This is the case of the GTK+ port, for example. So, this patch ensures that when a page is restored from the page cache, the main resource load delegates that are emitted until a response is received in normal loads, are emitted before the load is committed. Test: http/tests/loading/main-resource-delegates-on-back-navigation.html * loader/FrameLoader.cpp: (WebCore::FrameLoader::commitProvisionalLoad): When loading from the page cache, send delegate messages up to didReceiveResponse for the main resource before the load is committed, and the remaining messages afterwards. LayoutTests: Add test to check that main resource load delegates are emitted in the same order before the load is committed when loading a page from history with the page cache enabled and disabled. * http/tests/loading/main-resource-delegates-on-back-navigation-expected.txt: Added. * http/tests/loading/main-resource-delegates-on-back-navigation.html: Added. * http/tests/loading/resources/page-go-back-onload.html: Added. * loader/go-back-cached-main-resource-expected.txt: Canonical link: https://commits.webkit.org/171092@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@194888 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-01-12 08:23:36 +00:00
resources/first-page.html - willSendRequest <NSURLRequest URL resources/first-page.html, main document URL resources/first-page.html, http method GET> redirectResponse (null)
FrameLoaderClient::assignIdentifierToInitialRequest() not called for the main resource when loaded from the memory cache https://bugs.webkit.org/show_bug.cgi?id=112418 Source/WebCore: Reviewed by Darin Adler. When the main resource is loaded from the memory cache the response is not added to the ResponseVector of the document loader, so that when committing the provisional load the remaining delegate messages are not called because the ResponseVector of the document loader is empty. When the main resource is loaded from the memory cache, there's no resource loader, and the client is notified about the response received using ResourceLoadNotifier::dispatchDidReceiveResponse() directly instead of ResourceLoadNotifier::didReceiveResponse() which is the one adding the response to the ResponseVector of the document loader. So, the problem can be fixed by adding the response to the ResponseVector before calling dispatchDidReceiveResponse() when loading the main resource without a resource loade Test: loader/go-back-cached-main-resource.html * loader/DocumentLoader.cpp: (WebCore::DocumentLoader::responseReceived): LayoutTests: Patch by Manuel Rego Casasnovas <rego@igalia.com> on 2013-04-11 Reviewed by Darin Adler. * loader/go-back-cached-main-resource-expected.txt: Added. * loader/go-back-cached-main-resource.html: Added. * loader/resources/first-page.html: Added. * loader/resources/other-page.html: Added. * platform/gtk-wk1/loader/go-back-cached-main-resource-expected.txt: Added. * platform/wk2/loader/go-back-cached-main-resource-expected.txt: Added. Canonical link: https://commits.webkit.org/132797@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@148182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-04-11 08:25:51 +00:00
resources/first-page.html - didReceiveResponse <NSURLResponse resources/first-page.html, http status code 0>
resources/first-page.html - didFinishLoading
This test check the following situation:
First you navigate to a page (first-page.html).
Then you go to another page (other-page.html).
You repeat previous steps again (going to first-page.html and then to other-page.html).
Finally you click back.
The problem was that the resource load callbacks when going back to the cached main resource were not being called.
See bug #112418.