haikuwebkit/LayoutTests/svg/in-html/by-reference.html

41 lines
1.8 KiB
HTML
Raw Permalink Normal View History

<!DOCTYPE html>
<html>
<!--
SVG documents included by reference should be transparent. Any white visible in the green box is a failure.
-->
<head>
Use asynchronous ResourceHandleClient calls for WebKit1 https://bugs.webkit.org/show_bug.cgi?id=160677 Reviewed by Brady Eidson. Source/WebCore: Covered by existing tests. * PlatformAppleWin.cmake: * PlatformMac.cmake: * WebCore.xcodeproj/project.pbxproj: * loader/ResourceLoader.cpp: (WebCore::ResourceLoader::willSendRequestAsync): (WebCore::ResourceLoader::didReceiveResponseAsync): (WebCore::ResourceLoader::canAuthenticateAgainstProtectionSpaceAsync): * loader/ResourceLoader.h: * loader/appcache/ApplicationCacheGroup.cpp: (WebCore::ApplicationCacheGroup::didReceiveResponseAsync): (WebCore::ApplicationCacheGroup::willSendRequestAsync): (WebCore::ApplicationCacheGroup::canAuthenticateAgainstProtectionSpaceAsync): (WebCore::ApplicationCacheGroup::didReceiveResponse): Deleted. * loader/appcache/ApplicationCacheGroup.h: * platform/network/BlobResourceHandle.cpp: (WebCore::BlobResourceHandle::continueDidReceiveResponse): (WebCore::BlobResourceHandle::getSizeForNext): (WebCore::BlobResourceHandle::notifyResponseOnSuccess): (WebCore::BlobResourceHandle::notifyResponseOnError): * platform/network/PingHandle.h: * platform/network/ResourceHandle.cpp: (WebCore::ResourceHandle::didReceiveResponse): (WebCore::ResourceHandle::usesAsyncCallbacks): Deleted. * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.cpp: (WebCore::ResourceHandleClient::~ResourceHandleClient): (WebCore::ResourceHandleClient::willSendRequest): Deleted. (WebCore::ResourceHandleClient::willSendRequestAsync): Deleted. (WebCore::ResourceHandleClient::didReceiveResponseAsync): Deleted. (WebCore::ResourceHandleClient::canAuthenticateAgainstProtectionSpaceAsync): Deleted. * platform/network/ResourceHandleClient.h: (WebCore::ResourceHandleClient::didReceiveAuthenticationChallenge): (WebCore::ResourceHandleClient::didReceiveResponse): Deleted. (WebCore::ResourceHandleClient::usesAsyncCallbacks): Deleted. (WebCore::ResourceHandleClient::canAuthenticateAgainstProtectionSpace): Deleted. * platform/network/ResourceHandleInternal.h: (WebCore::ResourceHandleInternal::ResourceHandleInternal): * platform/network/SynchronousLoaderClient.cpp: (WebCore::SynchronousLoaderClient::willSendRequestAsync): (WebCore::SynchronousLoaderClient::canAuthenticateAgainstProtectionSpaceAsync): (WebCore::SynchronousLoaderClient::didReceiveResponseAsync): (WebCore::SynchronousLoaderClient::didFinishLoading): (WebCore::SynchronousLoaderClient::didFail): (WebCore::SynchronousLoaderClient::willSendRequest): Deleted. (WebCore::SynchronousLoaderClient::canAuthenticateAgainstProtectionSpace): Deleted. (WebCore::SynchronousLoaderClient::didReceiveResponse): Deleted. * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceHandleCFNet.cpp: (WebCore::ResourceHandle::createCFURLConnection): (WebCore::ResourceHandle::start): (WebCore::ResourceHandle::willSendRequest): (WebCore::ResourceHandle::shouldUseCredentialStorage): (WebCore::ResourceHandle::canAuthenticateAgainstProtectionSpace): (WebCore::ResourceHandle::platformLoadResourceSynchronously): * platform/network/cf/ResourceHandleCFURLConnectionDelegateWithOperationQueue.cpp: (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::ResourceHandleCFURLConnectionDelegateWithOperationQueue): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::releaseHandle): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::willSendRequest): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didReceiveResponse): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didReceiveData): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didFinishLoading): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didFail): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::willCacheResponse): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didReceiveChallenge): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didSendBodyData): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::shouldUseCredentialStorage): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::canRespondToProtectionSpace): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::continueCanAuthenticateAgainstProtectionSpace): * platform/network/cf/ResourceHandleCFURLConnectionDelegateWithOperationQueue.h: * platform/network/cf/SynchronousResourceHandleCFURLConnectionDelegate.cpp: Removed. * platform/network/cf/SynchronousResourceHandleCFURLConnectionDelegate.h: Removed. * platform/network/mac/ResourceHandleMac.mm: (WebCore::ResourceHandle::start): (WebCore::ResourceHandle::schedule): (WebCore::ResourceHandle::makeDelegate): (WebCore::ResourceHandle::delegate): (WebCore::ResourceHandle::platformLoadResourceSynchronously): (WebCore::ResourceHandle::willSendRequest): (WebCore::ResourceHandle::continueWillSendRequest): (WebCore::ResourceHandle::continueDidReceiveResponse): (WebCore::ResourceHandle::canAuthenticateAgainstProtectionSpace): (WebCore::ResourceHandle::continueCanAuthenticateAgainstProtectionSpace): (WebCore::ResourceHandle::continueWillCacheResponse): (WebCore::ResourceHandle::shouldUseCredentialStorage): Deleted. * platform/network/mac/WebCoreResourceHandleAsDelegate.h: Removed. * platform/network/mac/WebCoreResourceHandleAsDelegate.mm: Removed. * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.h: * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (-[WebCoreResourceHandleAsOperationQueueDelegate connection:willSendRequest:redirectResponse:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveAuthenticationChallenge:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveResponse:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveData:lengthReceived:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didSendBodyData:totalBytesWritten:totalBytesExpectedToWrite:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didFailWithError:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:willCacheResponse:]): Source/WebKitLegacy: * WebCoreSupport/WebResourceLoadScheduler.cpp: (WebResourceLoadScheduler::createPingHandle): Tools: * TestWebKitAPI/Tests/mac/SimplifyMarkup.mm: (TestWebKitAPI::TEST): The HTML being loaded contains an iframe, so testing if the main resource has loaded doesn't necessarily mean all subresources are loaded. Wait until they are loaded before continuing the test. This is a test of editing commands once the page has loaded, not a test of loading. LayoutTests: * TestExpectations: * platform/gtk/TestExpectations: * platform/ios-wk2/TestExpectations: * platform/mac-wk2/TestExpectations: * platform/wk2/TestExpectations: http/tests/cache/iframe-304-crash.html used to deterministically record its didFinishLoading callback, but only for WK1. It was marked as flaky for all WK2 ports. It is now flaky in WK1 because the order of the testRunner.notifyDone call and the didFinishLoading logging is no longer deterministic with asynchronous loading, but the test still verifies that there is no crash. http/tests/security/cross-origin-modal-dialog-base.html does navigation during showModalDialog, which probably should've never worked in WK1 and never worked in WK2. WK1 behavior now matches WK2 behavior. I'm not aware of any complaints about no navigation working during showModalDialog in WK2 and I imagine nobody will be regressed by this change, but if we do find such a problem, creative use of MessageQueues like we do with sync xhr in WK1 now could theoretically fix the problem, but we are trying to get rid of showModalDialog anyway. The test was written to verify that the SecurityOrigin doesn't fall back to the wrong origin, and it certainly doesn't now. These tests dump load delegate call order, which are less deterministic now but the tests still behave correctly. http/tests/svg/svg-use-external.html http/tests/loading/text-content-type-with-binary-extension.html http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-iframe-in-main-frame.html Canonical link: https://commits.webkit.org/195218@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224267 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-01 01:13:04 +00:00
<script>
if (window.testRunner)
testRunner.waitUntilDone();
var elementsLoaded = 0;
function loaded() {
if (window.testRunner && ++elementsLoaded == 5)
testRunner.notifyDone();
}
</script>
<style type='text/css'>
* {
margin: 0px;
padding: 0px;
}
div {
background-color: lime;
height: 400px;
width: 400px;
}
iframe {
border: none;
}
</style>
</head>
<body>
<div>
Use asynchronous ResourceHandleClient calls for WebKit1 https://bugs.webkit.org/show_bug.cgi?id=160677 Reviewed by Brady Eidson. Source/WebCore: Covered by existing tests. * PlatformAppleWin.cmake: * PlatformMac.cmake: * WebCore.xcodeproj/project.pbxproj: * loader/ResourceLoader.cpp: (WebCore::ResourceLoader::willSendRequestAsync): (WebCore::ResourceLoader::didReceiveResponseAsync): (WebCore::ResourceLoader::canAuthenticateAgainstProtectionSpaceAsync): * loader/ResourceLoader.h: * loader/appcache/ApplicationCacheGroup.cpp: (WebCore::ApplicationCacheGroup::didReceiveResponseAsync): (WebCore::ApplicationCacheGroup::willSendRequestAsync): (WebCore::ApplicationCacheGroup::canAuthenticateAgainstProtectionSpaceAsync): (WebCore::ApplicationCacheGroup::didReceiveResponse): Deleted. * loader/appcache/ApplicationCacheGroup.h: * platform/network/BlobResourceHandle.cpp: (WebCore::BlobResourceHandle::continueDidReceiveResponse): (WebCore::BlobResourceHandle::getSizeForNext): (WebCore::BlobResourceHandle::notifyResponseOnSuccess): (WebCore::BlobResourceHandle::notifyResponseOnError): * platform/network/PingHandle.h: * platform/network/ResourceHandle.cpp: (WebCore::ResourceHandle::didReceiveResponse): (WebCore::ResourceHandle::usesAsyncCallbacks): Deleted. * platform/network/ResourceHandle.h: * platform/network/ResourceHandleClient.cpp: (WebCore::ResourceHandleClient::~ResourceHandleClient): (WebCore::ResourceHandleClient::willSendRequest): Deleted. (WebCore::ResourceHandleClient::willSendRequestAsync): Deleted. (WebCore::ResourceHandleClient::didReceiveResponseAsync): Deleted. (WebCore::ResourceHandleClient::canAuthenticateAgainstProtectionSpaceAsync): Deleted. * platform/network/ResourceHandleClient.h: (WebCore::ResourceHandleClient::didReceiveAuthenticationChallenge): (WebCore::ResourceHandleClient::didReceiveResponse): Deleted. (WebCore::ResourceHandleClient::usesAsyncCallbacks): Deleted. (WebCore::ResourceHandleClient::canAuthenticateAgainstProtectionSpace): Deleted. * platform/network/ResourceHandleInternal.h: (WebCore::ResourceHandleInternal::ResourceHandleInternal): * platform/network/SynchronousLoaderClient.cpp: (WebCore::SynchronousLoaderClient::willSendRequestAsync): (WebCore::SynchronousLoaderClient::canAuthenticateAgainstProtectionSpaceAsync): (WebCore::SynchronousLoaderClient::didReceiveResponseAsync): (WebCore::SynchronousLoaderClient::didFinishLoading): (WebCore::SynchronousLoaderClient::didFail): (WebCore::SynchronousLoaderClient::willSendRequest): Deleted. (WebCore::SynchronousLoaderClient::canAuthenticateAgainstProtectionSpace): Deleted. (WebCore::SynchronousLoaderClient::didReceiveResponse): Deleted. * platform/network/SynchronousLoaderClient.h: * platform/network/cf/ResourceHandleCFNet.cpp: (WebCore::ResourceHandle::createCFURLConnection): (WebCore::ResourceHandle::start): (WebCore::ResourceHandle::willSendRequest): (WebCore::ResourceHandle::shouldUseCredentialStorage): (WebCore::ResourceHandle::canAuthenticateAgainstProtectionSpace): (WebCore::ResourceHandle::platformLoadResourceSynchronously): * platform/network/cf/ResourceHandleCFURLConnectionDelegateWithOperationQueue.cpp: (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::ResourceHandleCFURLConnectionDelegateWithOperationQueue): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::releaseHandle): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::willSendRequest): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didReceiveResponse): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didReceiveData): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didFinishLoading): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didFail): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::willCacheResponse): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didReceiveChallenge): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::didSendBodyData): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::shouldUseCredentialStorage): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::canRespondToProtectionSpace): (WebCore::ResourceHandleCFURLConnectionDelegateWithOperationQueue::continueCanAuthenticateAgainstProtectionSpace): * platform/network/cf/ResourceHandleCFURLConnectionDelegateWithOperationQueue.h: * platform/network/cf/SynchronousResourceHandleCFURLConnectionDelegate.cpp: Removed. * platform/network/cf/SynchronousResourceHandleCFURLConnectionDelegate.h: Removed. * platform/network/mac/ResourceHandleMac.mm: (WebCore::ResourceHandle::start): (WebCore::ResourceHandle::schedule): (WebCore::ResourceHandle::makeDelegate): (WebCore::ResourceHandle::delegate): (WebCore::ResourceHandle::platformLoadResourceSynchronously): (WebCore::ResourceHandle::willSendRequest): (WebCore::ResourceHandle::continueWillSendRequest): (WebCore::ResourceHandle::continueDidReceiveResponse): (WebCore::ResourceHandle::canAuthenticateAgainstProtectionSpace): (WebCore::ResourceHandle::continueCanAuthenticateAgainstProtectionSpace): (WebCore::ResourceHandle::continueWillCacheResponse): (WebCore::ResourceHandle::shouldUseCredentialStorage): Deleted. * platform/network/mac/WebCoreResourceHandleAsDelegate.h: Removed. * platform/network/mac/WebCoreResourceHandleAsDelegate.mm: Removed. * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.h: * platform/network/mac/WebCoreResourceHandleAsOperationQueueDelegate.mm: (-[WebCoreResourceHandleAsOperationQueueDelegate connection:willSendRequest:redirectResponse:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveAuthenticationChallenge:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:canAuthenticateAgainstProtectionSpace:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveResponse:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didReceiveData:lengthReceived:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didSendBodyData:totalBytesWritten:totalBytesExpectedToWrite:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:didFailWithError:]): (-[WebCoreResourceHandleAsOperationQueueDelegate connection:willCacheResponse:]): Source/WebKitLegacy: * WebCoreSupport/WebResourceLoadScheduler.cpp: (WebResourceLoadScheduler::createPingHandle): Tools: * TestWebKitAPI/Tests/mac/SimplifyMarkup.mm: (TestWebKitAPI::TEST): The HTML being loaded contains an iframe, so testing if the main resource has loaded doesn't necessarily mean all subresources are loaded. Wait until they are loaded before continuing the test. This is a test of editing commands once the page has loaded, not a test of loading. LayoutTests: * TestExpectations: * platform/gtk/TestExpectations: * platform/ios-wk2/TestExpectations: * platform/mac-wk2/TestExpectations: * platform/wk2/TestExpectations: http/tests/cache/iframe-304-crash.html used to deterministically record its didFinishLoading callback, but only for WK1. It was marked as flaky for all WK2 ports. It is now flaky in WK1 because the order of the testRunner.notifyDone call and the didFinishLoading logging is no longer deterministic with asynchronous loading, but the test still verifies that there is no crash. http/tests/security/cross-origin-modal-dialog-base.html does navigation during showModalDialog, which probably should've never worked in WK1 and never worked in WK2. WK1 behavior now matches WK2 behavior. I'm not aware of any complaints about no navigation working during showModalDialog in WK2 and I imagine nobody will be regressed by this change, but if we do find such a problem, creative use of MessageQueues like we do with sync xhr in WK1 now could theoretically fix the problem, but we are trying to get rid of showModalDialog anyway. The test was written to verify that the SecurityOrigin doesn't fall back to the wrong origin, and it certainly doesn't now. These tests dump load delegate call order, which are less deterministic now but the tests still behave correctly. http/tests/svg/svg-use-external.html http/tests/loading/text-content-type-with-binary-extension.html http/tests/security/contentSecurityPolicy/block-all-mixed-content/insecure-iframe-in-main-frame.html Canonical link: https://commits.webkit.org/195218@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@224267 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2017-11-01 01:13:04 +00:00
<object onload="loaded()" type='image/svg+xml' width='50' height='50' data='data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjxzdmcgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciLz4='></object>
<embed onload="loaded()" width='50' height='50' src='data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjxzdmcgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciLz4='></embed>
<iframe onload="loaded()" width='100' height='100' src='data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjxzdmcgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciLz4='></iframe>
<object onload="loaded()" type='text/xml' width='50' height='50' data='data:text/xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjxzdmcgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciLz4='></object>
<object onload="loaded()" type='application/xml' width='50' height='50' data='data:application/xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjxzdmcgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciLz4='></object-->
</div>
</body>
Add support for seamless attribute as well as seamless sandbox flag and default CSS styling https://bugs.webkit.org/show_bug.cgi?id=85302 Reviewed by Ojan Vafai. Source/WebCore: This also adds support for the seamless sandbox flag from HTML 5. The sandbox flag is not speficially overridable in the current HTML5, but it is set (like all sandbox flags) by default when sandbox is specified. Unfortunately this support is not yet observable in this patch, as this patch adds not observable features of seamless. This patch also adds the html.css additions for seamless, as specified: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#replaced-elements I noticed that my previous testing did not confirm that iframes marked for seamless (but not possible to display as seamless due to sandbox, etc.) were still to have this seamless styling. I've added additional testing for this case. I also added another test for the about:blank FIXME added as part of this change. In order to support srcdoc w/ seamless, we needed to move the srcdoc determination sooner in the initSecurityContext function (before the should-inherit early return). The next patch will make seamless actually observable from JS/DOM, this one just lays down all the plumbing, and separates the security aspects for easy review. Test: fast/frames/seamless/seamless-inherited-origin.html * css/html.css: (iframe:not([seamless])): (iframe[seamless]): * dom/Document.cpp: (WebCore::isEligibleForSeamless): (WebCore): (WebCore::Document::initSecurityContext): (WebCore::Document::seamlessParentIFrame): (WebCore::Document::shouldDisplaySeamlesslyWithParent): * dom/Document.h: (WebCore): (Document): * dom/SecurityContext.cpp: (WebCore::SecurityContext::SecurityContext): * dom/SecurityContext.h: (WebCore::SecurityContext::mayDisplaySeamlessWithParent): (SecurityContext): * html/HTMLAttributeNames.in: * html/HTMLIFrameElement.cpp: (WebCore::HTMLIFrameElement::shouldDisplaySeamlessly): (WebCore): * html/HTMLIFrameElement.h: (HTMLIFrameElement): * html/HTMLIFrameElement.idl: LayoutTests: Update all the test results now that the html.css changes have been added for seamless, as specified by HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#replaced-elements I also added a new test for about:blank iframes (per a code-FIXME) as well as some new testing to confirm that the default seamless-CSS style applies even when iframes cannot render seamless due to security restrictions. * fast/frames/seamless/seamless-basic-expected.txt: * fast/frames/seamless/seamless-basic.html: * fast/frames/seamless/seamless-inherited-origin-expected.txt: Added. * fast/frames/seamless/seamless-inherited-origin.html: Added. * fast/frames/seamless/seamless-inline-expected.txt: * fast/frames/seamless/seamless-min-max-expected.txt: * fast/frames/seamless/seamless-nested-expected.txt: * fast/frames/seamless/seamless-quirks-expected.txt: * fast/frames/seamless/seamless-sandbox-flag-expected.txt: * fast/frames/seamless/seamless-sandbox-flag.html: * fast/frames/seamless/seamless-sandbox-srcdoc-expected.txt: * http/tests/security/seamless/seamless-cross-origin-expected.txt: * http/tests/security/seamless/seamless-sandbox-srcdoc-expected.txt: * svg/in-html/by-reference.html: was using seamless, but really doens't want to, doing so just adds noise. Canonical link: https://commits.webkit.org/102859@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@115773 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2012-05-02 01:09:53 +00:00
</html>