1. 24 Jul, 2013 1 commit
  2. 23 Jul, 2013 1 commit
    • akling@apple.com's avatar
      REGRESSION(r150867): FrameView auto-sizing + delegate denied image load may... · d483f707
      akling@apple.com authored
      REGRESSION(r150867): FrameView auto-sizing + delegate denied image load may cause StyleResolver to re-enter itself.
      <rdar://problem/14324895>
      <http://webkit.org/b/119023>
      
      Reviewed by Simon Fraser.
      
      Source/WebCore:
      
      The bug happened when FrameView::autoSizeIfEnabled() was getting called below FrameLoader::checkCompleted()
      triggered by an incorrect loadDone() callback originating in SubresourceLoader::didCancel().
      
      * css/StyleResolver.cpp:
      (WebCore::StyleResolver::loadPendingResources):
      
          Add an assertion that this function is not getting re-entered. If a similar bug occurs
          in the future, this will help the lucky person debugging.
      
      * loader/SubresourceLoader.cpp:
      (WebCore::SubresourceLoader::didCancel):
      
          Don't notifyDone() if the SubresourceLoader is in Uninitialized state.
      
      Tools:
      
      Add a test for this rather specific problem.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2ObjC/PreventImageLoadWithAutoResizing.mm: Added.
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WebKit2ObjC/PreventImageLoadWithAutoResizing_Bundle.cpp: Added.
      (TestWebKitAPI::DenyWillSendRequestTest::DenyWillSendRequestTest):
      (TestWebKitAPI::DenyWillSendRequestTest::willSendRequestForFrame):
      (TestWebKitAPI::DenyWillSendRequestTest::didCreatePage):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153072 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d483f707
  3. 08 Jul, 2013 1 commit
  4. 05 Jul, 2013 1 commit
    • timothy_horton@apple.com's avatar
      [wk2] Add API to lock the scroll position at the top or bottom of the page · 8685d4e7
      timothy_horton@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118429
      <rdar://problem/14120323>
      
      Reviewed by Anders Carlsson.
      
      Test (API): WebKit2.ScrollPinningBehaviors
      
      * WebCore.exp.in:
      Expose FrameView::setScrollPinningBehavior.
      
      * page/FrameView.cpp:
      (WebCore::FrameView::FrameView):
      Our pinning behavior should be DoNotPin by default.
      
      * page/FrameView.cpp:
      (WebCore::FrameView::minimumScrollPosition):
      (WebCore::FrameView::maximumScrollPosition):
      * page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm:
      (WebCore::ScrollingTreeScrollingNodeMac::minimumScrollPosition):
      (WebCore::ScrollingTreeScrollingNodeMac::maximumScrollPosition):
      Fix the minimum scroll position's vertical location to the maximum if
      we're pinned to the bottom, and vice-versa if we're pinned to the top.
      
      (WebCore::FrameView::setScrollPinningBehavior): Added.
      If scroll pinning behavior has changed, inform ScrollingCoordinator
      and update scrollbars (which will also re-pin the scroll position).
      
      * page/FrameView.h:
      Override minimumScrollPosition, add setScrollPinningBehavior,
      and storage for m_scrollPinningBehavior.
      
      * page/scrolling/ScrollingCoordinator.h:
      (WebCore::ScrollingCoordinator::setScrollPinningBehavior): Added.
      
      * page/scrolling/ScrollingTree.cpp:
      (WebCore::ScrollingTree::ScrollingTree):
      Our pinning behavior should be DoNotPin by default.
      
      (WebCore::ScrollingTree::setScrollPinningBehavior):
      (WebCore::ScrollingTree::scrollPinningBehavior):
      Getter/setter for m_scrollPinningBehavior, scrolling-thread-safe.
      
      * page/scrolling/ScrollingTree.h:
      * page/scrolling/mac/ScrollingCoordinatorMac.h:
      * page/scrolling/mac/ScrollingCoordinatorMac.mm:
      (WebCore::ScrollingCoordinatorMac::setScrollPinningBehavior):
      Inform ScrollingTree of the scroll pinning behavior change.
      
      * platform/ScrollTypes.h:
      Add ScrollPinningBehavior enum.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/ScrollPinningBehaviors.cpp: Added.
      (TestWebKitAPI::didFinishDocumentLoadForFrame):
      (TestWebKitAPI::TEST):
      Add a test that ensures that the three pinning modes (DoNotPin, PinToTop, PinToBottom)
      all work correctly in the face of resizing the view and scrolling from JS.
      
      * Shared/WebPageCreationParameters.cpp:
      (WebKit::WebPageCreationParameters::encode):
      (WebKit::WebPageCreationParameters::decode):
      * Shared/WebPageCreationParameters.h:
      Pass the current ScrollPinningBehavior across to the WebPage upon creation.
      
      * UIProcess/API/C/WKPage.cpp:
      (WKPageGetScrollPinningBehavior):
      (WKPageSetScrollPinningBehavior):
      * UIProcess/API/C/WKPagePrivate.h:
      SPI to get/set the WebPageProxy's current ScrollPinningBehavior.
      Convert between WK API type and WebCore enum.
      
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::WebPageProxy):
      (WebKit::WebPageProxy::creationParameters):
      Send ScrollPinningBehavior when creating a WebPage.
      
      (WebKit::WebPageProxy::setScrollPinningBehavior):
      Pass ScrollPinningBehavior changes across to the WebProcess (and save it
      in WebPageProxy so it can be sent back across if the WebProcess crashes).
      
      * UIProcess/WebPageProxy.h:
      (WebKit::WebPageProxy::scrollPinningBehavior):
      Getter/setter and storage for m_scrollPinningBehavior.
      
      * WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
      (WebKit::WebFrameLoaderClient::transitionToCommittedForNewPage):
      Inform new FrameViews of the current ScrollPinningBehavior.
      
      * WebProcess/WebPage/WebPage.cpp:
      (WebKit::WebPage::WebPage):
      Set our ScrollPinningBehavior based on our creation parameters.
      
      (WebKit::WebPage::setScrollPinningBehavior):
      Inform the FrameView of ScrollPinningBehavior changes.
      
      * WebProcess/WebPage/WebPage.h:
      (WebKit::WebPage::scrollPinningBehavior): Added.
      (WebKit::WebPage::setScrollPinningBehavior): Added.
      Add storage for m_scrollPinningBehavior.
      
      * WebProcess/WebPage/WebPage.messages.in:
      Add SetScrollPinningBehavior message.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152425 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8685d4e7
  5. 01 Jul, 2013 1 commit
    • timothy_horton@apple.com's avatar
      Maximum scroll position can be negative in some cases · ed528286
      timothy_horton@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118175
      <rdar://problem/14301217>
      
      Reviewed by Anders Carlsson.
      
      Test (API): WebKit2.ResizeReversePaginatedWebView
      
      * page/FrameView.cpp:
      (WebCore::FrameView::maximumScrollPosition):
      * page/FrameView.h:
      Override maximumScrollPosition() in FrameView and don't clamp to zero if
      a reverse pagination mode is enabled, as it is possible (and common) to
      have a negative maximum scroll position with reverse pagination.
      
      * platform/ScrollView.cpp:
      (WebCore::ScrollView::updateScrollbars):
      Drive-by adoption of toIntSize().
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/ResizeReversePaginatedWebView.cpp: Added.
      (TestWebKitAPI::didRunJavaScript):
      (TestWebKitAPI::didLayout):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WebKit2/lots-of-text-vertical-lr.html: Added.
      Add a test that loads a vertical-lr document, paginates it horizontally
      from right to left, resizes the view to fit the entire document, and
      verifies that the scroll position is negative, as it must be for the
      document to be enclosed by the view.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@152265 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ed528286
  6. 28 Jun, 2013 1 commit
  7. 14 Jun, 2013 1 commit
    • enrica@apple.com's avatar
      WKPageFindStringMatches ignores the kWKFindOptionsBackwards option. · 3dec912d
      enrica@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=117647
      <rdar://problem/13881024>
      
      Source/WebCore: 
      
      Reviewed by Darin Adler.
              
      The API returns the matched ranges in the DOM order regardless of the
      find direction, but the index of the first match after the user selection
      should take the find direction into account.
      
      Extended existing test in TestWebKitAPI.
      
      * page/Page.cpp:
      (WebCore::Page::findStringMatchingRanges): Added handling of the Backwards case.
      * page/Page.h: Fixed incorrect name of the enum.
      
      Source/WebKit2: 
      
      Reviewed by Darin Adler.
              
      The API returns the matched ranges in the DOM order regardless of the
      find direction, but the index of the first match after the user selection
      should take the find direction into account.
      
      Extended existing test in TestWebKitAPI.
      
      * Shared/API/c/WKFindOptions.h: Added enum for the case where there are
      no matches after the user selection in the direction of the find.
      
      Tools: 
      
      Reviewed by Darin Adler.
              
      The test now uses content with a selection and tests both
      forwards and backward find as well as the case of a find
      that has no matches after the user selection.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/FindMatches.mm:
      (TestWebKitAPI::didFindStringMatches):
      * TestWebKitAPI/Tests/WebKit2/findRanges.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151607 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3dec912d
  8. 31 May, 2013 1 commit
    • commit-queue@webkit.org's avatar
      Move MD5, SHA1 unit tests from WTF to TestWebKitAPI · aa1f1cc7
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=116445
      
      Patch by Zan Dobersek <zdobersek@igalia.com> on 2013-05-31
      Reviewed by Benjamin Poulain.
      
      Source/WTF:
      
      Remove the MD5 and SHA1 test cases from the WTF code. The same cases are now built and run under TestWebKitAPI.
      
      * wtf/MD5.cpp:
      (WTF::MD5::MD5):
      * wtf/SHA1.cpp:
      (WTF::SHA1::SHA1):
      
      Tools:
      
      Add the MD5 and SHA1 unit tests that were previously located inside WTF.
      
      * TestWebKitAPI/CMakeLists.txt:
      * TestWebKitAPI/GNUmakefile.am:
      * TestWebKitAPI/TestWebKitAPI.vcxproj/TestWebKitAPI.vcxproj:
      * TestWebKitAPI/TestWebKitAPI.vcxproj/TestWebKitAPI.vcxproj.filters:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WTF/MD5.cpp: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::expectMD5):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WTF/SHA1.cpp: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::expectSHA1):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WTF/WTF.pro:
      * TestWebKitAPI/win/TestWebKitAPI.vcproj:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@151012 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      aa1f1cc7
  9. 21 May, 2013 2 commits
    • jberlin@webkit.org's avatar
      Expose a way to know when forms are added to a page or when form controls are added to a form · f13d0a3d
      jberlin@webkit.org authored
      in the injected bundle
      https://bugs.webkit.org/show_bug.cgi?id=116334
      
      Reviewed by Alexey Proskuryakov.
      
      Source/WebKit2:
      
      Add shouldNotifyOnFormChanges and didAssociateFormControls to the WKBundlePageFormClient.
      
      * WebProcess/InjectedBundle/API/c/WKBundlePage.h:
      Add the new callbacks as part of version 2 of the WKBundlePageFormClient.
      
      * WebProcess/InjectedBundle/InjectedBundlePageFormClient.cpp:
      (WebKit::InjectedBundlePageFormClient::didAssociateFormControls):
      Pass the message along to the client if the client has a handler.
      (WebKit::InjectedBundlePageFormClient::shouldNotifyOnFormChanges):
      Ditto.
      * WebProcess/InjectedBundle/InjectedBundlePageFormClient.h:
      
      * WebProcess/WebCoreSupport/WebChromeClient.cpp:
      (WebKit::WebChromeClient::didAssociateFormControls):
      Tell the injected bundle form client for the page.
      (WebKit::WebChromeClient::shouldNotifyOnFormChanges):
      Ditto.
      * WebProcess/WebCoreSupport/WebChromeClient.h:
      
      Tools:
      
      Add tests for the new callbacks.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      Add DidAssociateFormControls/_Bundle.cpp and associate-form-controls.html
      
      * TestWebKitAPI/Tests/WebKit2/DidAssociateFormControls.cpp: Added.
      (TestWebKitAPI::nullJavaScriptCallback):
      A "null" callback to handle the fact that WKPageRunJavaScriptInMainFrame cannot handle null
      being passed in for the callback.
      (TestWebKitAPI::didReceiveMessageFromInjectedBundle):
      After receiving the message that didAssociateFormControls callback was invoked from adding
      the form in the onload handler, tell the page to add a password field to the form, which
      should also invoke didAssociateFormControls callback.
      (TestWebKitAPI::setInjectedBundleClient):
      Register to receive messages.
      (TestWebKitAPI::TEST):
      Load associate-form-controls.html and wait until the didAssociateFormControls callback has
      been invoked for both adding the form and for adding a password field to the form.
      
      * TestWebKitAPI/Tests/WebKit2/DidAssociateFormControls_Bundle.cpp: Added.
      (TestWebKitAPI::shouldNotifyOnFormChanges):
      Return true so the didAssociateFormControls callback is invoked.
      (TestWebKitAPI::didAssociateFormControls):
      Tell the UI process.
      (TestWebKitAPI::DidAssociateFormControlsTest::DidAssociateFormControlsTest):
      (TestWebKitAPI::DidAssociateFormControlsTest::didCreatePage):
      Register for the shouldNotifyOnFormChanges and didAssociateFormControls callbacks.
      
      * TestWebKitAPI/Tests/WebKit2/associate-form-controls.html: Added.
      Add a form in response to the onload event. Add a button that will add the password field
      for manual testing.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150441 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f13d0a3d
    • lforschler@apple.com's avatar
      Source/WebKit2: Rollout r150398. · b4f5bdcd
      lforschler@apple.com authored
      Tools:     Rollout 150398.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150424 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b4f5bdcd
  10. 20 May, 2013 1 commit
    • jberlin@webkit.org's avatar
      Expose a way to know when forms are added to a page or when form controls are added to a form · 3e17a40b
      jberlin@webkit.org authored
      in the injected bundle
      https://bugs.webkit.org/show_bug.cgi?id=116334
      
      Reviewed by Alexey Proskuryakov.
      
      Source/WebKit2:
      
      Add shouldNotifyOnFormChanges and didAssociateFormControls to the WKBundlePageFormClient.
      
      * WebProcess/InjectedBundle/API/c/WKBundlePage.h:
      Add the new callbacks as part of version 2 of the WKBundlePageFormClient.
      
      * WebProcess/InjectedBundle/InjectedBundlePageFormClient.cpp:
      (WebKit::InjectedBundlePageFormClient::didAssociateFormControls):
      Pass the message along to the client if the client has a handler.
      (WebKit::InjectedBundlePageFormClient::shouldNotifyOnFormChanges):
      Ditto.
      * WebProcess/InjectedBundle/InjectedBundlePageFormClient.h:
      
      * WebProcess/WebCoreSupport/WebChromeClient.cpp:
      (WebKit::WebChromeClient::didAssociateFormControls):
      Tell the injected bundle form client for the page.
      (WebKit::WebChromeClient::shouldNotifyOnFormChanges):
      Ditto.
      * WebProcess/WebCoreSupport/WebChromeClient.h:
      
      Tools:
      
      Add tests for the new callbacks.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      Add DidAssociateFormControls/_Bundle.cpp and associate-form-controls.html
      
      * TestWebKitAPI/Tests/WebKit2/DidAssociateFormControls.cpp: Added.
      (TestWebKitAPI::nullJavaScriptCallback):
      A "null" callback to handle the fact that WKPageRunJavaScriptInMainFrame cannot handle null
      being passed in for the callback.
      (TestWebKitAPI::didReceiveMessageFromInjectedBundle):
      After receiving the message that didAssociateFormControls callback was invoked from adding
      the form in the onload handler, tell the page to add a password field to the form, which
      should also invoke didAssociateFormControls callback.
      (TestWebKitAPI::setInjectedBundleClient):
      Register to receive messages.
      (TestWebKitAPI::TEST):
      Load associate-form-controls.html and wait until the didAssociateFormControls callback has
      been invoked for both adding the form and for adding a password field to the form.
      
      * TestWebKitAPI/Tests/WebKit2/DidAssociateFormControls_Bundle.cpp: Added.
      (TestWebKitAPI::shouldNotifyOnFormChanges):
      Return true so the didAssociateFormControls callback is invoked.
      (TestWebKitAPI::didAssociateFormControls):
      Tell the UI process.
      (TestWebKitAPI::DidAssociateFormControlsTest::DidAssociateFormControlsTest):
      (TestWebKitAPI::DidAssociateFormControlsTest::didCreatePage):
      Register for the shouldNotifyOnFormChanges and didAssociateFormControls callbacks.
      
      * TestWebKitAPI/Tests/WebKit2/associate-form-controls.html: Added.
      Add a form in response to the onload event. Add a button that will add the password field
      for manual testing.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150398 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3e17a40b
  11. 16 May, 2013 1 commit
    • weinig@apple.com's avatar
      Add variants of the loading APIs that take user data and a way for the... · 147cb451
      weinig@apple.com authored
      Add variants of the loading APIs that take user data and a way for the injected bundle to find out about them
      https://bugs.webkit.org/show_bug.cgi?id=116132
      
      Reviewed by Anders Carlsson.
      
      Adds "WithUserData" versions of all the load APIs and two new WKBundlePageLoaderClient functions,
      willLoadURLRequest and willLoadDataRequest to let the bundle access them.
      
      Source/WebKit2: 
      
      Adds WebKit2WillLoadTest.* API tests.
      
      * UIProcess/API/C/WKPage.cpp:
      (WKPageLoadURLWithUserData):
      (WKPageLoadURLRequestWithUserData):
      (WKPageLoadFile):
      (WKPageLoadFileWithUserData):
      (WKPageLoadHTMLStringWithUserData):
      (WKPageLoadAlternateHTMLStringWithUserData):
      (WKPageLoadPlainTextStringWithUserData):
      (WKPageLoadWebArchiveDataWithUserData):
      * UIProcess/API/C/WKPage.h:
      * UIProcess/WebPageProxy.cpp:
      * UIProcess/WebPageProxy.h:
      (WebPageProxy):
      * WebKit2.xcodeproj/project.pbxproj:
      * WebProcess/InjectedBundle/API/c/WKBundlePage.h:
      * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.cpp:
      (WebKit::InjectedBundlePageLoaderClient::willLoadURLRequest):
      (WebKit::InjectedBundlePageLoaderClient::willLoadDataRequest):
      * WebProcess/InjectedBundle/InjectedBundlePageLoaderClient.h:
      (WebCore):
      (InjectedBundlePageLoaderClient):
      * WebProcess/WebPage/WebPage.cpp:
      * WebProcess/WebPage/WebPage.h:
      * WebProcess/WebPage/WebPage.messages.in:
      
      Tools: 
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/WillLoad.cpp: Added.
      * TestWebKitAPI/Tests/WebKit2/WillLoad_Bundle.cpp: Added.
      * WebKitTestRunner/InjectedBundle/InjectedBundlePage.cpp:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@150242 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      147cb451
  12. 11 May, 2013 1 commit
    • andersca@apple.com's avatar
      Crash when terminating a process that has not been fully launched · d8a9a51a
      andersca@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=115962
      <rdar://problem/13660916>
      
      Reviewed by Andreas Kling.
      
      Source/WebKit2:
      
      Handle terminating a process that has not been fully launched.
      
      * UIProcess/Launcher/ProcessLauncher.cpp:
      (WebKit::ProcessLauncher::didFinishLaunchingProcess):
      If we have been invalidated, dispose the connection identifier.
      
      * UIProcess/Launcher/mac/ProcessLauncherMac.mm:
      (WebKit::ProcessLauncher::terminateProcess):
      If we're still launching the process, invalidate so the client won't get an unexpected
      didFinishLaunching callback.
      
      * UIProcess/WebProcessProxy.cpp:
      (WebKit::WebProcessProxy::requestTermination):
      Check if webConnection() is null before calling it. (It will be null if the process isn't fully launched).
      
      Tools:
      
      Add TerminateTwice, a test that terminates a page, then reloads it and terminates it again
      before the process has had a chance to be fully launched.
      
      * TestWebKitAPI/GNUmakefile.am:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/TerminateTwice.cpp: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::didFinishLoadForFrame):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WebKit2/WebKit2.pro:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149933 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d8a9a51a
  13. 08 May, 2013 1 commit
    • aestes@apple.com's avatar
      [WebKit2] REGRESSION (Custom Protocols): Reproducible crash when navigating to... · 4fa77596
      aestes@apple.com authored
      [WebKit2] REGRESSION (Custom Protocols): Reproducible crash when navigating to URL with an invalid scheme
      https://bugs.webkit.org/show_bug.cgi?id=115790
      
      Reviewed by Alexey Proskuryakov.
      
      Source/WebKit2:
      
      NSMutableSet does not support adding or removing nil objects, and
      WTF::HashSet does not support adding, removing, or checking for null
      WTF::Strings.
      
      For the NSMutableSet case, make sure that we don't try to add or remove
      nil NSStrings.
      
      For the WTF::HashSet case, NSURL will return a nil NSString if we ask
      it for its scheme when it is invalid, which we will convert to a null
      WTF::String. Don't try to check if our HashSet of registered schemes
      contains a null String.
      
      * Shared/Network/CustomProtocols/mac/CustomProtocolManagerMac.mm:
      (WebKit::CustomProtocolManager::registerScheme): Assert that the scheme
      isn't null. We reject null schemes at the WKBrowsingContextController level.
      (WebKit::CustomProtocolManager::unregisterScheme): Ditto.
      (WebKit::CustomProtocolManager::supportsScheme): If scheme is null, return false.
      * UIProcess/API/mac/WKBrowsingContextController.mm:
      (+[WKBrowsingContextController registerSchemeForCustomProtocol:]): Do not register a nil scheme.
      (+[WKBrowsingContextController unregisterSchemeForCustomProtocol:]): Ditto.
      
      Tools:
      
      Added two API tests:
      
      1) Verify that +[WKBrowsingContextController (un)registerSchemeForCustomProtocol:] can be called with a nil NSString without crashing.
      2) Verify that +[WKCustomProtocol canInitWithRequest:] does not crash when passed an NSURLRequest with an invalid scheme.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2ObjC/CustomProtocolsInvalidScheme.mm: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WebKit2ObjC/CustomProtocolsInvalidScheme_Bundle.cpp: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::decidePolicyForNavigationAction):
      (CustomProtocolInvalidSchemeTest):
      (TestWebKitAPI::CustomProtocolInvalidSchemeTest::CustomProtocolInvalidSchemeTest):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149774 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4fa77596
  14. 06 May, 2013 1 commit
    • aestes@apple.com's avatar
      REGRESSION (r125592): Reproducible crash in DOMWindow::open when a delegate... · 7e025ae5
      aestes@apple.com authored
      REGRESSION (r125592): Reproducible crash in DOMWindow::open when a delegate closes the new window in decidePolicyForNavigationAction
      https://bugs.webkit.org/show_bug.cgi?id=115609
      
      Reviewed by Oliver Hunt.
      
      Source/WebCore:
      
      When a window created by window.open() is navigated, the embedder might
      close it in decidePolicyForNavigationAction. If this happens, we end up
      with a pointer to a deleted Frame.
      
      Fix this by keeping a strong reference to the Frame created by
      createWindow(). We can later determine if the window was closed by
      checking if the new Frame has a detached Page.
      
      Added an API test: WebKit1.CloseNewWindowInNavigationPolicyDelegate.
      
      * page/DOMWindow.cpp:
      (WebCore::DOMWindow::createWindow):
      
      Tools:
      
      Added an API test.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/mac/CloseNewWindowInNavigationPolicyDelegate.mm: Added.
      (+[TestDelegate shared]):
      (-[TestDelegate webView:decidePolicyForNavigationAction:request:frame:decisionListener:]):
      (-[TestDelegate webView:createWebViewWithRequest:]):
      (TestWebKitAPI):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/mac/OpenNewWindow.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149589 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7e025ae5
  15. 04 May, 2013 1 commit
  16. 26 Apr, 2013 1 commit
    • aestes@apple.com's avatar
      [WebKit2] Loading a resource from a custom protocol in a synchronous XHR times out · 756003ad
      aestes@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=115223
      
      Reviewed by Darin Adler.
      
      Source/WebKit2:
      
      When WebKit performs a synchronous load on the Mac, it spins a nested
      run loop in a mode that only accepts input from the NSURLConnection
      performing the load. When the load is for a custom protocol in WebKit2,
      we proxy it to the UI process via CoreIPC messages, but the response
      messages from the UI process are never processed as long as the run
      loop is in a non-common mode (and we wouldn't want to process messages
      that could re-enter WebCore in the middle of loading, anyway). Since
      these messages never make it back to the NSURLConnection handling the
      request, the connection eventually times out.
      
      Fix this by using a work queue to handle custom protocol messages in
      the networking process. The work queue can process incoming custom
      protocol messages while the main thread is blocked.
      
      * NetworkProcess/NetworkProcess.cpp:
      (WebKit::NetworkProcess::initializeConnection): Called
      initializeConnection() on all the NetworkProcess's supplements.
      * Shared/ChildProcessSupplement.h: Added a base class for
      NetworkProcessSupplement and WebProcessSupplement which defines
      initializeConnection and provides an empty default implementation.
      (WebKit::ChildProcessSupplement::~ChildProcessSupplement):
      (WebKit::ChildProcessSupplement::initializeConnection):
      * Shared/Network/CustomProtocols/CustomProtocolManager.h:
      * Shared/Network/CustomProtocols/mac/CustomProtocolManagerMac.mm:
      (WebKit::CustomProtocolManager::CustomProtocolManager): Instantiated a
      work queue for message processing.
      (WebKit::CustomProtocolManager::initializeConnection): Added the work
      queue as a message receiver on the CoreIPC connection.
      (WebKit::CustomProtocolManager::initialize): If we're in the web
      process and the network process is being used, unregister and destroy
      the work queue we previously created. It'd be better to not create it
      in the first place, but we have to register our work queue with the
      CoreIPC connection before it is established, which is before the UI
      process has told us whether the network process is in use.
      * Shared/Network/NetworkProcessSupplement.h: Inherited from
      ChildProcessSupplement.
      * WebKit2.xcodeproj/project.pbxproj: Added ChildProcessSupplement.h.
      * WebProcess/WebProcess.cpp:
      (WebKit::WebProcess::initializeConnection): Called
      initializeConnection() on all the WebProcess's supplements.
      * WebProcess/WebProcessSupplement.h: Inherited from
      ChildProcessSupplement.
      
      Tools:
      
      Added an API test.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: Added new files.
      * TestWebKitAPI/Tests/CustomProtocolsSyncXHRTest.mm: Added.
      (TestWebKitAPI::TEST): Tested that a synchronous XHR does not time out
      when it loads a request with a custom protocol.
      * TestWebKitAPI/Tests/WebKit2/custom-protocol-sync-xhr.html: Added.
      * TestWebKitAPI/Tests/WebKit2ObjC/CustomProtocolsTest.mm: Moved the
      NSURLProtocol subclass to TestProtocol.{h, mm} and did some
      miscellaneous cleanup.
      * TestWebKitAPI/mac/TestProtocol.h: Copied from Source/WebKit2/WebProcess/WebProcessSupplement.h.
      * TestWebKitAPI/mac/TestProtocol.mm: Copied from Tools/TestWebKitAPI/Tests/WebKit2ObjC/CustomProtocolsTest.mm.
      (+[TestProtocol canInitWithRequest:]):
      (+[TestProtocol canonicalRequestForRequest:]):
      (+[TestProtocol requestIsCacheEquivalent:toRequest:]):
      (+[TestProtocol scheme]):
      (-[TestProtocol startLoading]):
      (-[TestProtocol stopLoading]):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@149194 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      756003ad
  17. 22 Apr, 2013 1 commit
    • benjamin@webkit.org's avatar
      Remove the memory instrumentation code · 9d72cb0b
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=114931
      
      Reviewed by Andreas Kling.
      
      .: 
      
      * Source/autotools/symbols.filter:
      
      Source/JavaScriptCore: 
      
      * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
      * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
      
      Source/WebCore: 
      
      The Memory Instrumentation code is unfinished and has already
      become out of sync the objects it is supposed to represent.
      
      The current approach does not seem maintainable, it is better to
      remove it before someone gets hurt.
      
      By removing the code, the binary become 1240976 bytes smaller.
      Yep, almost 1 Mb, bringing WebCore to the size it has 5 months ago :)
      
      * MostWebCoreFiles: remove the support for memory instrumentation.
      
      Source/WebKit: 
      
      * WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:
      
      Source/WebKit/mac: 
      
      * WebView/WebRenderLayer.mm:
      
      Source/WebKit/win: 
      
      * WebKit.vcproj/WebKitExports.def.in:
      
      Source/WTF: 
      
      On Mac x86_64, the code removal cause the binary to be
      9224 bytes smaller.
      
      * GNUmakefile.list.am:
      * WTF.pro:
      * WTF.vcproj/WTF.vcproj:
      * WTF.vcxproj/WTF.vcxproj:
      * WTF.vcxproj/WTF.vcxproj.filters:
      * WTF.xcodeproj/project.pbxproj:
      * wtf/CMakeLists.txt:
      * wtf/Forward.h:
      * wtf/ListHashSet.h:
      (ListHashSet):
      (ListHashSetNodeAllocator):
      (WTF::ListHashSetNodeAllocator::pool):
      (WTF::ListHashSetNodeAllocator::pastPool):
      * wtf/MemoryInstrumentation.cpp: Removed.
      * wtf/MemoryInstrumentation.h: Removed.
      * wtf/MemoryInstrumentationArrayBufferView.h: Removed.
      * wtf/MemoryInstrumentationHashCountedSet.h: Removed.
      * wtf/MemoryInstrumentationHashMap.h: Removed.
      * wtf/MemoryInstrumentationHashSet.h: Removed.
      * wtf/MemoryInstrumentationListHashSet.h: Removed.
      * wtf/MemoryInstrumentationSequence.h: Removed.
      * wtf/MemoryInstrumentationString.h: Removed.
      * wtf/MemoryInstrumentationVector.h: Removed.
      * wtf/MemoryObjectInfo.h: Removed.
      * wtf/text/AtomicString.h:
      * wtf/text/StringImpl.h:
      (WTF::StringImpl::isASCIILiteral):
      * wtf/text/WTFString.h:
      
      Tools: 
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WTF/MemoryInstrumentationTest.cpp: Removed.
      
      LayoutTests: 
      
      * inspector/profiler/memory-instrumentation-cached-images-expected.txt: Removed.
      * inspector/profiler/memory-instrumentation-cached-images.html: Removed.
      * inspector/profiler/memory-instrumentation-canvas-expected.txt: Removed.
      * inspector/profiler/memory-instrumentation-canvas.html: Removed.
      * inspector/profiler/memory-instrumentation-external-array-expected.txt: Removed.
      * inspector/profiler/memory-instrumentation-external-array.html: Removed.
      * inspector/profiler/memory-instrumentation-external-string-expected.txt: Removed.
      * inspector/profiler/memory-instrumentation-external-string.html: Removed.
      * inspector/profiler/memory-instrumentation-test.js: Removed.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148921 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9d72cb0b
  18. 13 Apr, 2013 1 commit
    • andersca@apple.com's avatar
      Add form delegate method that's invoked right before sending a submit event to a form element · e5e98f73
      andersca@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=114575
      
      Reviewed by Dan Bernstein.
      
      Source/WebCore:
      
      * WebCore.exp.in:
      Export a symbol.
      
      * WebCore.xcodeproj/project.pbxproj:
      Make DOMHTMLFormElementInternal.h a private header.
      
      Source/WebKit/mac:
      
      * MigrateHeaders.make:
      Copy DOMHTMLFormElementInternal.h over to WebKit.
      
      * WebCoreSupport/WebFrameLoaderClient.mm:
      (makeFormFieldValuesDictionary):
      New helper function that returns the values of a form in dictionary form.
      
      (WebFrameLoaderClient::dispatchWillSendSubmitEvent):
      Call the right delegate method.
      
      (WebFrameLoaderClient::dispatchWillSubmitForm):
      Use the helper function.
      
      * WebView/WebDelegateImplementationCaching.h:
      * WebView/WebDelegateImplementationCaching.mm:
      (CallFormDelegate):
      Add another overload.
      
      * WebView/WebFormDelegate.h:
      * WebView/WebFormDelegate.m:
      (-[WebFormDelegate willSendSubmitEventToForm:inFrame:withValues:]):
      Add a default implementation.
      
      Tools:
      
      Add a test.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/mac/WillSendSubmitEvent.mm: Added.
      (-[FormDelegate willSendSubmitEventToForm:inFrame:withValues:]):
      (TestWebKitAPI):
      (TestWebKitAPI::TEST):
      
      * TestWebKitAPI/mac/PlatformUtilitiesMac.mm:
      (TestWebKitAPI::Util::toSTD):
      Don't crash when a null NSString is passed to toSTD.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148368 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e5e98f73
  19. 12 Apr, 2013 1 commit
    • benjamin@webkit.org's avatar
      [WK2] WebPageProxy loadURL() won't work when called just after terminateProcess() · 21e7432e
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=110743
      
      Patch by Adenilson Cavalcanti <cavalcantii@gmail.com> on 2013-04-12
      Reviewed by Benjamin Poulain.
      
      Source/WebKit2: 
      
      A call to loadURL() just after terminating WebProcess will fail thanks to
      WebPageProxy being in an undefined state since it is in the middle of its own
      cleanup after process termination.
      
      To properly fix this, not only WebPageProxy cleanup should be made
      at WebProcess termination request, but also WebProcessProxy needs
      to only return to its caller after terminating the process and
      closing connections. Otherwise, WebPageProxy can even be able to
      detect that WebProcess is no longer running, but a call to respawn
      the process will fail.
      
      To fix these issues, this patch moves the cleanup code to a shared private function
      that is used for both the cases i.e. user termination and real crash. WebProcess
      shutdown is done using a new method that ensures that all cleanup was done before
      returning.
      
      A last change introduced in this patch is that for user requested termination,
      clients are no longer notified of a crash (since it is not a crash).
      
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::terminateProcess):
      (WebKit::WebPageProxy::processDidCrash):
      (WebKit):
      (WebKit::WebPageProxy::resetStateAfterProcessExited):
      * UIProcess/WebPageProxy.h:
      (WebPageProxy):
      * UIProcess/WebProcessProxy.cpp:
      (WebKit::WebProcessProxy::userRequestedTerminate):
      (WebKit):
      * UIProcess/WebProcessProxy.h:
      (WebProcessProxy):
      
      Tools: 
      
      Adding a new test file to check if loading a page just after WebProcess
      has crashed (or was terminated) works. The test executes the
      following steps (Load, Crash, Load), thus stressing WebProcess
      reattach and process termination code path.
      
      * TestWebKitAPI/GNUmakefile.am:
      * TestWebKitAPI/PlatformEfl.cmake:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/MouseMoveAfterCrash.cpp:
      (TestWebKitAPI::setPageLoaderClient):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WebKit2/LoadPageOnCrash.cpp: Added.
      (TestWebKitAPI):
      (WebKit2CrashLoader):
      (TestWebKitAPI::WebKit2CrashLoader::WebKit2CrashLoader):
      (TestWebKitAPI::WebKit2CrashLoader::loadUrl):
      (TestWebKitAPI::WebKit2CrashLoader::crashWebProcess):
      (TestWebKitAPI::didFinishLoad):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/Tests/WebKit2/WebKit2.pro:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148312 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      21e7432e
  20. 02 Mar, 2013 1 commit
    • darin@apple.com's avatar
      StringHasher functions require alignment that call sites do not all guarantee · 08fec633
      darin@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=110171
      
      Reviewed by Benjamin Poulain.
      
      Source/WebCore:
      
      * platform/graphics/WidthCache.h:
      (WebCore::WidthCache::SmallStringKey::SmallStringKey): Use the newly added
      addCharactersAssumingAligned to make sure we don't slow this call site down.
      It's safe since this code always adds characters two at a time.
      
      Source/WTF:
      
      The StringHasher class is optimized for clients who pass it two characters at
      a time. However, the function named addCharacters did not make this clear to
      clients, and one calculateStringHashAndLengthFromUTF8MaskingTop8Bits got it wrong.
      Fix by making addCharacters work regardless of hasher alignment and adding a new
      function, addCharactersAssumingAligned, for use when we want a faster path and can
      guarantee we are adding characters two at a time.
      
      * wtf/StringHasher.h:
      (WTF::StringHasher::addCharactersAssumingAligned): Renamed the addCharacters function
      addCharactersAssumingAligned, since it only works if the hasher is currently aligned,
      meaning it contains an even number of characters. The function already asserts
      that this is true, but the calculateStringHashAndLengthFromUTF8MaskingTop8Bits
      function was using it in cases where the assertion could fire. Also updated to
      call addCharactersInternal by its new name. Also added some new overloads that take
      data pointers and lengths so callers can always use addCharactersAssumingAligned
      instead of addCharacters if they know the hasher is aligned.
      (WTF::StringHasher::addCharacter): Updated to call the public
      addCharactersAssumingAligned function since that's simpler and a bit cleaner.
      (WTF::StringHasher::addCharacters): Added functions with this name that handle
      the case where the hasher is not aligned. These will be called by existing call sites
      that were formerly using the function named addCharactersAssumingAligned above.
      Also add an overload that works with the default converter automatically.
      (WTF::StringHasher::computeHashAndMaskTop8Bits): Changed to call
      addCharactersAssumingAligned to eliminate copied and pasted code. The hasher is empty,
      so definitely aligned.
      (WTF::StringHasher::computeHash): Ditto.
      (WTF::StringHasher::addCharactersInternal): Renamed from addCharactersToHash, since
      the former name did not make clear how this differs from the public functions.
      The real difference is that this is like addCharactersAssumingAligned, but without
      the assertion, so addCharactersAssumingAligned is called instead, even within the
      class's implementation.
      
      Tools:
      
      * TestWebKitAPI/CMakeLists.txt:
      * TestWebKitAPI/GNUmakefile.am:
      * TestWebKitAPI/TestWebKitAPI.gypi:
      * TestWebKitAPI/TestWebKitAPI.vcxproj/TestWebKitAPI.vcxproj:
      * TestWebKitAPI/TestWebKitAPI.vcxproj/TestWebKitAPI.vcxproj.filters:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WTF/WTF.pro:
      * TestWebKitAPI/win/TestWebKitAPI.vcproj:
      Added the StringHasher.cpp file.
      
      * TestWebKitAPI/Tests/WTF/StringHasher.cpp: Added. Contains a bunch of tests
      for the functions in the StringHasher class.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@144552 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      08fec633
  21. 25 Feb, 2013 1 commit
    • jpfau@apple.com's avatar
      Optionally partition cache to prevent using cache for tracking · 97c6a7f9
      jpfau@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=110269
      
      Reviewed by Maciej Stachowiak.
      
      Source/JavaScriptCore:
      
      * Configurations/FeatureDefines.xcconfig: Add defines for cache partitioning and public suffix list usage
      
      Source/WebCore:
      
      Implement memory cache partitioning by passing the cache name through
      resource requests into a new version of resourceForURL.
      
      Test: http/tests/cache/partitioned-cache.html
      
      * Configurations/FeatureDefines.xcconfig: Add defines for cache partitioning and public suffix list usage
      * WebCore.exp.in: Export new functions for WKSI and test suite
      * WebCore.xcodeproj/project.pbxproj:
      * html/DOMURL.cpp:
      (WebCore::DOMURL::revokeObjectURL): Retrofit for new resourceForRequest function
      * inspector/InspectorPageAgent.cpp:
      (WebCore::InspectorPageAgent::cachedResource): Retrofit for new resourceForRequest function
      * inspector/InspectorResourceAgent.cpp:
      (WebCore::InspectorResourceAgent::replayXHR): Retrofit for new resourceForRequest function
      * loader/DocumentLoader.h:
      (DocumentLoader):
      (WebCore::DocumentLoader::recordMemoryCacheLoadForFutureClientNotification): Retrofit for new resourceForRequest function
      (WebCore::DocumentLoader::takeMemoryCacheLoadsForClientNotification): Retrofit for new resourceForRequest function
      * loader/FrameLoader.cpp:
      (WebCore::FrameLoader::loadedResourceFromMemoryCache): Retrofit for new resourceForRequest function
      (WebCore::FrameLoader::tellClientAboutPastMemoryCacheLoads): Retrofit for new resourceForRequest function
      * loader/archive/cf/LegacyWebArchive.cpp:
      (WebCore::LegacyWebArchive::create): Retrofit for new resourceForRequest function
      * loader/cache/CachedResource.cpp:
      (WebCore::CachedResource::~CachedResource):
      * loader/cache/CachedResource.h: Retrofit for new resourceForRequest function
      (CachedResource):
      (WebCore::CachedResource::cachePartition):
      * loader/cache/CachedResourceLoader.cpp:
      (WebCore::CachedResourceLoader::requestUserCSSStyleSheet): Retrofit for new resourceForRequest function
      (WebCore::CachedResourceLoader::requestResource): Retrofit for new resourceForRequest function
      (WebCore::CachedResourceLoader::loadResource): Retrofit for new resourceForRequest function
      * loader/cache/MemoryCache.cpp:
      (WebCore):
      (WebCore::partitionName): Add function for determining absolute partition name
      (WebCore::MemoryCache::add): Retrofit for partition mapping
      (WebCore::MemoryCache::revalidationSucceeded): Retrofit for partition mapping
      (WebCore::MemoryCache::resourceForURL): Call into new resourceForRequest
      (WebCore::MemoryCache::resourceForRequest): Retrofit for partition mapping
      (WebCore::MemoryCache::evict): Retrofit for partition mapping
      (WebCore::MemoryCache::removeResourcesWithOrigin): Retrofit for partition mapping
      (WebCore::MemoryCache::getOriginsWithCache): Retrofit for partition mapping
      (WebCore::MemoryCache::removeUrlFromCache): Retrofit for partition mapping
      (WebCore::MemoryCache::removeRequestFromCache): Retrofit for partition mapping
      (WebCore::MemoryCache::removeRequestFromCacheImpl): Retrofit for partition mapping
      (WebCore::MemoryCache::crossThreadRemoveRequestFromCache): Add function for calling removeRequestFromCacheImpl that takes a CrossThreadResourceRequestData
      (WebCore::MemoryCache::getStatistics): Retrofit for partition mapping
      (WebCore::MemoryCache::setDisabled): Retrofit for partition mapping
      * loader/cache/MemoryCache.h:
      (MemoryCache):
      * page/SecurityOrigin.cpp:
      (WebCore):
      (WebCore::SecurityOrigin::cachePartition): Add function for determining the cache partition name
      * page/SecurityOrigin.h:
      (SecurityOrigin):
      * platform/PublicSuffix.h: Added.
      (WebCore):
      * platform/mac/PublicSuffixMac.mm: Added.
      (WebCore):
      (WebCore::isPublicSuffix):
      (WebCore::topPrivatelyControlledDomain):
      * platform/mac/WebCoreSystemInterface.h:
      * platform/mac/WebCoreSystemInterface.mm:
      * platform/network/cf/ResourceRequest.h:
      (ResourceRequest):
      (WebCore::ResourceRequest::cachePartition):
      (WebCore::ResourceRequest::setCachePartition):
      (CrossThreadResourceRequestData):
      * platform/network/cf/ResourceRequestCFNet.cpp:
      (WebCore::ResourceRequest::doPlatformCopyData): Pass through cache partition name
      (WebCore):
      (WebCore::ResourceRequest::doPlatformAdopt): Pass through cache partition name
      * platform/network/mac/ResourceRequestMac.mm:
      (WebCore::ResourceRequest::doUpdateResourceRequest): Pass through cache partition name
      (WebCore::ResourceRequest::doUpdatePlatformRequest): Pass through cache partition name
      
      Source/WebKit/mac:
      
      Update WKSI bindings and add feature defines.
      
      * Configurations/FeatureDefines.xcconfig: Add defines for cache partitioning and public suffix list usage
      * WebCoreSupport/WebSystemInterface.mm:
      (InitWebCoreSystemInterface):
      
      Source/WebKit2:
      
      Update WKSI bindings and add feature defines.
      
      * Configurations/FeatureDefines.xcconfig: Add defines for cache partitioning and public suffix list usage
      * WebCoreSupport/WebSystemInterface.mm:
      (InitWebCoreSystemInterface):
      
      Tools:
      
      Add test suite for public suffix functions on Mac.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/mac/PublicSuffix.mm: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::TEST_F):
      
      WebKitLibraries:
      
      Update WKSI bindings.
      
      * WebKitSystemInterface.h:
      * libWebKitSystemInterfaceLion.a:
      * libWebKitSystemInterfaceMountainLion.a:
      
      LayoutTests:
      
      Added tests for ensuring the cache partitioning functions
      
      * http/tests/cache/partitioned-cache-expected.txt: Added.
      * http/tests/cache/partitioned-cache.html: Added.
      * http/tests/cache/resources/echo-cookie.cgi: Added.
      * http/tests/cache/resources/partitioned-cache-loader.html: Added.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@143986 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      97c6a7f9
  22. 21 Feb, 2013 1 commit
    • mhahnenberg@apple.com's avatar
      Objective-C API: Need a way to use the Objective-C JavaScript API with WebKit · f0712f94
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106059
      
      Source/JavaScriptCore: 
      
      Reviewed by Geoffrey Garen.
              
      * API/JSBase.h: Renamed enable flag for API.
      * API/JSBlockAdaptor.h: Using new flag.
      * API/JSBlockAdaptor.mm: Ditto.
      * API/JSContext.h: Add convenience C API conversion function for JSGlobalContextRef.
      * API/JSContext.mm: 
      (-[JSContext JSGlobalContextRef]): Implementation of C API convenience function.
      (-[JSContext initWithVirtualMachine:]): We don't use the m_apiData field any more.
      (-[JSContext initWithGlobalContextRef:]): init method for allocating new JSContexts given a JSGlobalContextRef.
      (-[JSContext dealloc]): No more m_apiData.
      (-[JSContext wrapperForObjCObject:]): Renamed wrapperForObject. 
      (-[JSContext wrapperForJSObject:]): Fetches or allocates the JSValue for the specified JSValueRef in this JSContext.
      (+[JSContext contextWithGlobalContextRef:]): Helper function to grab the lightweight JSContext wrapper for a given
      JSGlobalContextRef from the global wrapper cache or allocate a new one if there isn't already one.
      * API/JSContextInternal.h: New flag, new method declaration for initWithGlobalContextRef.
      * API/JSExport.h: New flag.
      * API/JSValue.h: New flag and new C API convenience method.
      * API/JSValue.mm:
      (-[JSValue JSValueRef]): Implementation of the C API convenience method.
      (objectToValueWithoutCopy):
      (+[JSValue valueWithValue:inContext:]): We now ask the JSContext for an Objective-C JSValue wrapper, which it can cache
      in its internal JSWrapperMap.
      * API/JSValueInternal.h:
      * API/JSVirtualMachine.h:
      * API/JSVirtualMachine.mm: Added global cache that maps JSContextGroupRef -> JSVirtualMachine lightweight wrappers.
      (wrapperCacheLock):
      (initWrapperCache):
      (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
      (+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
      (-[JSVirtualMachine init]):
      (-[JSVirtualMachine initWithContextGroupRef:]):
      (-[JSVirtualMachine dealloc]):
      (+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
      (-[JSVirtualMachine contextForGlobalContextRef:]):
      (-[JSVirtualMachine addContext:forGlobalContextRef:]):
      * API/JSVirtualMachineInternal.h:
      * API/JSWrapperMap.h:
      * API/JSWrapperMap.mm:
      (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We use the JSObjectSetPrototype C API call because 
      setting the __proto__ property causes all sorts of bad things to happen behind the scenes, which can cause crashes based on 
      when it gets called.
      (-[JSWrapperMap initWithContext:]):
      (-[JSWrapperMap jsWrapperForObject:]):
      (-[JSWrapperMap objcWrapperForJSValueRef:]):
      * API/JavaScriptCore.h:
      * API/ObjCCallbackFunction.h:
      * API/ObjCCallbackFunction.mm:
      (ObjCCallbackFunction::ObjCCallbackFunction): We never actually should have retained the target in the case that we had a 
      block as a callback. Blocks are initially allocated on the stack and are only moved to the heap if we call their copy method.
      Retaining the block on the stack was a bad idea because if that stack frame ever went away and we called the block later, 
      we'd crash and burn.
      (ObjCCallbackFunction::setContext): We need a new setter for when the weak reference to a JSContext inside an ObjCCallbackFunction
      disappears, we can allocate a new one in its place.
      (ObjCCallbackFunction):
      (objCCallbackFunctionCallAsFunction): Reset the callback's context if it's ever destroyed.
      (objCCallbackFunctionForInvocation): Again, don't set the __proto__ property because it uses black magic that can cause us to crash
      depending on when this is called.
      (objCCallbackFunctionForBlock): Here is where we copy the block to the heap when we're first creating the callback object for it.
      * API/tests/testapi.c:
      (main):
      * API/tests/testapi.mm: We're going to get rid of the automatic block conversion, since that is causing leaks. I changed it 
      here in this test just so that it wouldn't mask any other potential leaks. Also modified some of the tests since JSContexts are 
      just lightweight wrappers now, we're not guaranteed to get the same pointer back from the call to [JSValue context] as the one 
      that the value was created in.
      (-[TestObject callback:]):
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * runtime/JSGlobalData.cpp:
      (JSC::JSGlobalData::JSGlobalData): No more m_apiData.
      * runtime/JSGlobalData.h: Ditto.
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::JSGlobalObject): Ditto.
      * runtime/JSGlobalObject.h:
      
      Source/WebCore: 
      
      Reviewed by Geoffrey Garen.
      
      * WebCore.exp.in:
      * bindings/js/JSDOMWindowShell.cpp:
      (WebCore::JSDOMWindowShell::setWindow): Since we're basically abandoning a JSDOMWindow here, we call
      garbageCollectSoon().
      * bindings/js/JSDOMWindowShell.h:
      * bindings/js/ScriptController.h: New function to get the JSContext for the global object of the current main world.
      * bindings/js/ScriptControllerMac.mm: 
      (WebCore::ScriptController::javaScriptContext): Ditto.
      * bindings/objc/WebScriptObject.h: Added ifdef guards. Also new convenience conversion function for the JSC Obj-C API.
      * bindings/objc/WebScriptObject.mm: JSC::JSValue and JSValue conflict with one another, so we have to be more specific.
      (-[WebScriptObject _globalContextRef]): Useful helper function for getting the JSGlobalContextRef of a particular WebScriptObject.
      (-[WebScriptObject callWebScriptMethod:withArguments:]):
      (-[WebScriptObject evaluateWebScript:]):
      (-[WebScriptObject valueForKey:]):
      (-[WebScriptObject webScriptValueAtIndex:]):
      (+[WebScriptObject _convertValueToObjcValue:JSC::originRootObject:rootObject:]):
      (-[WebScriptObject JSValue]): Implementation of convenience WebScriptObject conversion function to new Objective-C API.
      * bindings/objc/WebScriptObjectPrivate.h:
      
      Source/WebKit/mac: 
      
      Reviewed by Geoffrey Garen.
      
      Addition of appropriate delegate callbacks and support to the WebKit API.
      
      * WebCoreSupport/WebFrameLoaderClient.mm:
      * WebView/WebDelegateImplementationCaching.h:
      (WebFrameLoadDelegateImplementationCache):
      * WebView/WebFrame.h:
      * WebView/WebFrame.mm:
      (-[WebFrame _stringByEvaluatingJavaScriptFromString:forceUserGesture:]):
      (-[WebFrame _stringByEvaluatingJavaScriptFromString:withGlobalObject:inScriptWorld:]):
      (-[WebFrame _javaScriptContextForScriptWorld:]):
      (-[WebFrame javaScriptContext]):
      * WebView/WebFrameLoadDelegate.h:
      * WebView/WebFramePrivate.h:
      * WebView/WebScriptDebugDelegate.mm:
      (-[WebScriptCallFrame _convertValueToObjcValue:JSC::]):
      (-[WebScriptCallFrame exception]):
      (-[WebScriptCallFrame evaluateWebScript:]):
      * WebView/WebScriptWorld.h:
      * WebView/WebScriptWorld.mm:
      (+[WebScriptWorld scriptWorldForJavaScriptContext:]):
      * WebView/WebView.mm:
      (-[WebView _cacheFrameLoadDelegateImplementations]):
      (aeDescFromJSValue):
      (-[WebView aeDescByEvaluatingJavaScriptFromString:]):
      (-[WebView _computedStyleIncludingVisitedInfo:forElement:]):
      
      Source/WTF: 
      
      Reviewed by Geoffrey Garen.
      
      * wtf/FeatureDefines.h: Added enable flag for JSC Objective-C API so it can be used in
      export files.
      
      Tools: 
      
      Reviewed by Geoffrey Garen.
      
      Added new tests for the WebKit API portion of the JSC Objective-C API.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/mac/JSContextBackForwardCache1.html: Added.
      * TestWebKitAPI/Tests/mac/JSContextBackForwardCache2.html: Added.
      * TestWebKitAPI/Tests/mac/WebViewDidCreateJavaScriptContext.mm: Added.
      (-[MyConsole log:]):
      (-[MyConsole printHelloWorld]):
      (-[MyConsole add:to:]):
      (-[DidCreateJavaScriptContextFrameLoadDelegate webView:didFinishLoadForFrame:]):
      (-[DidCreateJavaScriptContextFrameLoadDelegate webView:didCreateJavaScriptContext:forFrame:]):
      (TestWebKitAPI):
      (TestWebKitAPI::TEST):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@143637 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      f0712f94
  23. 15 Feb, 2013 1 commit
  24. 12 Feb, 2013 3 commits
    • commit-queue@webkit.org's avatar
      [WK2] Page reloading will crash UIProcess after WebProcess was killed · 994a2a11
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=109305
      
      Patch by Adenilson Cavalcanti <cavalcantii@gmail.com> on 2013-02-12
      Reviewed by Benjamin Poulain.
      
      Source/WebKit2:
      
      Re-initialize the pointer to a WebInspectorProxy object before calling
      initializeWebPage().
      
      When the WebProcess crashes, WebPageProxy::processDidCrash() will
      set WebInspectorProxy pointer to null, which later is accessed by
      initializeWebPage(). This patch avoids a crash scenario where
      calls into a null pointer would be made.
      
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::reattachToWebProcess):
      
      Tools:
      
      Adding a new test to simulate the case of WebProcess crash followed by a trying
      to load a new page.
      
      * TestWebKitAPI/GNUmakefile.am:
      * TestWebKitAPI/PlatformEfl.cmake:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/ReloadPageAfterCrash.cpp: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::didFinishLoad):
      (TestWebKitAPI::TEST):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142704 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      994a2a11
    • jberlin@webkit.org's avatar
      Rollout r142618, it broke all the Mac builds. · a0e76f54
      jberlin@webkit.org authored
      Source/WebCore:
      
      * inspector/HeapGraphSerializer.cpp:
      (WebCore::HeapGraphSerializer::HeapGraphSerializer):
      (WebCore::HeapGraphSerializer::pushUpdate):
      (WebCore::HeapGraphSerializer::reportNode):
      (WebCore::HeapGraphSerializer::toNodeId):
      (WebCore::HeapGraphSerializer::addRootNode):
      * inspector/HeapGraphSerializer.h:
      (WebCore):
      (HeapGraphSerializer):
      * inspector/InspectorMemoryAgent.cpp:
      (WebCore::InspectorMemoryAgent::getProcessMemoryDistributionImpl):
      
      Tools:
      
      * TestWebKitAPI/TestWebKitAPI.gypi:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebCore/HeapGraphSerializerTest.cpp: Removed.
      * TestWebKitAPI/win/TestWebKitAPI.vcproj:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142637 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a0e76f54
    • loislo@chromium.org's avatar
      Web Inspector: Native Memory Instrumentation: reportLeaf method doesn't report... · 30c4b2f6
      loislo@chromium.org authored
      Web Inspector: Native Memory Instrumentation: reportLeaf method doesn't report the leaf node properly.
      https://bugs.webkit.org/show_bug.cgi?id=109554
      
      Source/WebCore:
      
      In some cases leaves have no pointer so with the old schema we can't generate nodeId for them because we
      can't insert 0 into hashmap. It happens when we call addPrivateBuffer method.
      
      Drive by fix: I introduced a client interface for the HeapGraphSerializer.
      It helps me to do the tests for the serializer.
      
      Reviewed by Yury Semikhatsky.
      
      It is covered by newly added tests in TestWebKitAPI.
      
      * inspector/HeapGraphSerializer.cpp:
      (WebCore::HeapGraphSerializer::HeapGraphSerializer):
      (WebCore::HeapGraphSerializer::pushUpdate):
      (WebCore::HeapGraphSerializer::reportNode):
      (WebCore::HeapGraphSerializer::toNodeId):
      (WebCore::HeapGraphSerializer::addRootNode):
      * inspector/HeapGraphSerializer.h:
      (HeapGraphSerializerClient):
      (WebCore::HeapGraphSerializerClient::~HeapGraphSerializerClient):
      (HeapGraphSerializer):
      * inspector/InspectorMemoryAgent.cpp:
      (WebCore::InspectorMemoryAgent::getProcessMemoryDistributionImpl):
      
      Tools:
      
      In some cases leaves have no pointer. As example when we report a leaf via addPrivateBuffer.
      This patch has new set of tests for HeapGraphSerializer.
      
      Reviewed by Yury Semikhatsky.
      
      * TestWebKitAPI/TestWebKitAPI.gypi:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebCore/HeapGraphSerializerTest.cpp: Added.
      * TestWebKitAPI/win/TestWebKitAPI.vcproj:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142618 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      30c4b2f6
  25. 09 Feb, 2013 1 commit
    • commit-queue@webkit.org's avatar
      Make TestWebKitAPI work for iOS · a09e465f
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=108978
      
      Patch by David Farler <dfarler@apple.com> on 2013-02-09
      Reviewed by David Kilzer.
      
      Source/WebCore:
      
      Tests already exist - refactor only.
      
      * WebCore.exp.in: Lumped __ZNK7WebCore4KURL7hasPathEv with related methods.
      * platform/KURL.cpp: Inlined hasPath() into the header
      * platform/KURL.h: Inlined hasPath() into the header
      
      Tools:
      
      * Makefile: Added TestWebKitAPI to iOS MODULES list.
      * TestWebKitAPI/Configurations/Base.xcconfig:
      - Include FeatureDefines
      - Removed VALID_ARCHS
      - Removed FRAMEWORK_SEARCH_PATHS - allows building against other SDKs
      - Excluded source files per platform
      * TestWebKitAPI/Configurations/TestWebKitAPI.xcconfig:
      - framework and library switches per platform
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      - Remove explicit framework and library linking (moved to xcconfigs)
      - Added iOS main.mm
      * TestWebKitAPI/config.h:
      - Guard importing Cocoa.h and WebKit2_C.h on iOS
      * TestWebKitAPI/ios/mainIOS.mm: Copied from Tools/TestWebKitAPI/mac/main.mm.
      * TestWebKitAPI/mac/mainMac.mm: Renamed from Tools/TestWebKitAPI/mac/main.mm.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142381 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a09e465f
  26. 04 Feb, 2013 1 commit
  27. 31 Jan, 2013 1 commit
    • enrica@apple.com's avatar
      WebKit2: provide new bundle APIs to allow bundle clients to be notified of pasteboard access. · 7eb1d5bc
      enrica@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=108396.
      <rdar://problem/12920461>
      
      Source/WebCore: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds support in WebCore to new EditorClient methods to support the modified
      client bundle API in WebKit2.
      
      * WebCore.exp.in:
      * editing/Editor.cpp:
      (WebCore::Editor::cut): Added call to willWriteSelectionToPasteboard.
      (WebCore::Editor::copy): Ditto.
      (WebCore::Editor::willWriteSelectionToPasteboard): Added.
      * editing/Editor.h:
      * loader/EmptyClients.h: Added empty client implementation
      for the new methods.
      (WebCore::EmptyEditorClient::willWriteSelectionToPasteboard):
      (WebCore::EmptyEditorClient::getClientPasteboardDataForRange):
      * page/EditorClient.h:
      * platform/mac/PasteboardMac.mm:
      (WebCore::Pasteboard::writeSelectionForTypes): Added call to getClientPasteboardDataForRange.
      
      Source/WebKit/blackberry: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebCoreSupport/EditorClientBlackBerry.cpp:
      (WebCore::EditorClientBlackBerry::willWriteSelectionToPasteboard):
      (WebCore::EditorClientBlackBerry::getClientPasteboardDataForRange):
      * WebCoreSupport/EditorClientBlackBerry.h:
      
      Source/WebKit/chromium: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * src/EditorClientImpl.cpp:
      (WebKit::EditorClientImpl::willWriteSelectionToPasteboard):
      (WebKit::EditorClientImpl::getClientPasteboardDataForRange):
      * src/EditorClientImpl.h:
      
      Source/WebKit/efl: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebCoreSupport/EditorClientEfl.cpp:
      (WebCore::EditorClientEfl::willWriteSelectionToPasteboard):
      (WebCore::EditorClientEfl::getClientPasteboardDataForRange):
      * WebCoreSupport/EditorClientEfl.h:
      
      Source/WebKit/gtk: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebCoreSupport/EditorClientGtk.cpp:
      (WebKit::EditorClient::willWriteSelectionToPasteboard):
      (WebKit::EditorClient::getClientPasteboardDataForRange):
      * WebCoreSupport/EditorClientGtk.h:
      
      Source/WebKit/mac: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebCoreSupport/WebEditorClient.h:
      * WebCoreSupport/WebEditorClient.mm:
      (WebEditorClient::willWriteSelectionToPasteboard):
      (WebEditorClient::getClientPasteboardDataForRange):
      
      Source/WebKit/qt: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebCoreSupport/EditorClientQt.cpp:
      (WebCore::EditorClientQt::willWriteSelectionToPasteboard):
      (WebCore::EditorClientQt::getClientPasteboardDataForRange):
      * WebCoreSupport/EditorClientQt.h:
      
      Source/WebKit/win: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebCoreSupport/WebEditorClient.cpp:
      (WebEditorClient::willWriteSelectionToPasteboard):
      (WebEditorClient::getClientPasteboardDataForRange):
      * WebCoreSupport/WebEditorClient.h:
      
      Source/WebKit/wince: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebCoreSupport/EditorClientWinCE.cpp:
      (WebKit::EditorClientWinCE::willWriteSelectionToPasteboard):
      (WebKit::EditorClientWinCE::getClientPasteboardDataForRange):
      * WebCoreSupport/EditorClientWinCE.h:
      
      Source/WebKit/wx: 
      
      Reviewed by Alexey Proskuryakov.
      
      Adds stub implementation for WebKit of the new EditorClient methods.
      
      * WebKitSupport/EditorClientWx.cpp:
      (WebCore::EditorClientWx::willWriteSelectionToPasteboard):
      (WebCore::EditorClientWx::getClientPasteboardDataForRange):
      * WebKitSupport/EditorClientWx.h:
      
      Source/WebKit2: 
      
      Reviewed by Alexey Proskuryakov.
      
      This patch adds new bundle client API to receive notifications
      relative the pasteboard activity. There are 2 new API added to
      InjectedBundleEditorClient, to receive notification before and
      after the pasteboard content is added and one API to provide
      additional content to add to the pasteboard.
      In order to create content to add to the pasteboard, WKWebArchiveRef
      and WKWebArchiveResourcesRef have been added to the set of API level
      object.
      This work is a joint effort with Sam Weinig who contributed the
      support for WKWebArchiveRef, WKWebArchiveResourcesRef and related
      files. Sam is the author of the first chunk of changes listed below.
              
      * Shared/API/c/WKBase.h:
      * Shared/API/c/WKSharedAPICast.h:
      * Shared/API/c/mac/WKWebArchive.cpp: Added.
      (WKWebArchiveGetTypeID):
      (WKWebArchiveCreate):
      (WKWebArchiveCreateWithData):
      (WKWebArchiveCreateFromRange):
      (WKWebArchiveCopyMainResource):
      (WKWebArchiveCopySubresources):
      (WKWebArchiveCopySubframeArchives):
      (WKWebArchiveCopyData):
      * Shared/API/c/mac/WKWebArchive.h: Added.
      * Shared/API/c/mac/WKWebArchiveResource.cpp: Added.
      (WKWebArchiveResourceGetTypeID):
      (WKWebArchiveResourceCreate):
      (WKWebArchiveResourceCopyData):
      (WKWebArchiveResourceCopyURL):
      (WKWebArchiveResourceCopyMIMEType):
      (WKWebArchiveResourceCopyTextEncoding):
      * Shared/API/c/mac/WKWebArchiveResource.h: Added.
      * Shared/APIObject.h:
      * Shared/WebArchive.cpp: Added.
      (WebKit::WebArchive::create):
      (WebKit::WebArchive::WebArchive):
      (WebKit::WebArchive::~WebArchive):
      (WebKit::WebArchive::mainResource):
      (WebKit::WebArchive::subresources):
      (WebKit::WebArchive::subframeArchives):
      (WebKit::releaseCFData):
      (WebKit::WebArchive::data):
      (WebKit::WebArchive::coreLegacyWebArchive):
      * Shared/WebArchive.h: Added.
      (WebKit::WebArchive::type):
      * Shared/WebArchiveResource.cpp: Added.
      (WebKit::WebArchiveResource::create):
      (WebKit::WebArchiveResource::WebArchiveResource):
      (WebKit::WebArchiveResource::~WebArchiveResource):
      (WebKit::releaseCFData):
      (WebKit::WebArchiveResource::data):
      (WebKit::WebArchiveResource::URL):
      (WebKit::WebArchiveResource::MIMEType):
      (WebKit::WebArchiveResource::textEncoding):
      (WebKit::WebArchiveResource::coreArchiveResource):
      * Shared/WebArchiveResource.h: Added.
      (WebKit::WebArchiveResource::type):
      * WebKit2.xcodeproj/project.pbxproj:
              
      * Shared/APIClientTraits.cpp: Added versioning to InjectedBundlePageEditorClient.
      * Shared/APIClientTraits.h:
      * WebProcess/InjectedBundle/API/c/WKBundlePage.h:
      * WebProcess/InjectedBundle/InjectedBundlePageEditorClient.cpp:
      (WebKit::InjectedBundlePageEditorClient::willWriteToPasteboard): Added.
      (WebKit::InjectedBundlePageEditorClient::getPasteboardDataForRange): Added.
      (WebKit::InjectedBundlePageEditorClient::didWriteToPasteboard): Added.
      * WebProcess/InjectedBundle/InjectedBundlePageEditorClient.h:
      * WebProcess/WebCoreSupport/WebEditorClient.cpp:
      (WebKit::WebEditorClient::didWriteSelectionToPasteboard):
      (WebKit::WebEditorClient::willWriteSelectionToPasteboard):
      (WebKit::WebEditorClient::getClientPasteboardDataForRange):
      * WebProcess/WebCoreSupport/WebEditorClient.h:
      
      Tools: 
      
      Reviewed by Alexey Proskuryakov.
              
      Adding new WebKit2 test with relevant bundle, to test the new APIs.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/PasteboardNotifications.mm: Added.
      (TestWebKitAPI::didReceiveMessageFromInjectedBundle):
      (TestWebKitAPI::setInjectedBundleClient):
      * TestWebKitAPI/Tests/WebKit2/PasteboardNotifications_Bundle.cpp: Added.
      (PasteboardNotificationsTest):
      (TestWebKitAPI::willWriteToPasteboard):
      (TestWebKitAPI::getPasteboardDataForRange):
      (TestWebKitAPI::didWriteToPasteboard):
      (TestWebKitAPI::PasteboardNotificationsTest::PasteboardNotificationsTest):
      (TestWebKitAPI::PasteboardNotificationsTest::didCreatePage):
      * TestWebKitAPI/Tests/WebKit2/execCopy.html: Added.
      * WebKitTestRunner/InjectedBundle/InjectedBundlePage.cpp: Updated to reflect
      changes in InjectedBundleEditorClient.
      (WTR::InjectedBundlePage::InjectedBundlePage):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141473 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7eb1d5bc
  28. 28 Jan, 2013 2 commits
    • joepeck@webkit.org's avatar
      [Mac] Update PageVisibilityState when WebView is hidden / visible · 2152e36f
      joepeck@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=107509
      
      Source/WebKit/mac:
      
      Reviewed by NOBODY (OOPS!).
      
      * WebView/WebView.mm:
      * WebView/WebViewPrivate.h:
      (-[WebView _commonInitializationWithFrameName:groupName:]):
      Set the initial visibility of the page.
      
      (-[WebView addWindowObserversForWindow:]):
      (-[WebView removeWindowObservers]):
      (-[WebView _isViewVisible]):
      (-[WebView _updateVisibilityState]):
      (-[WebView viewDidMoveToWindow]):
      (-[WebView _windowVisibilityChanged:]):
      Update visibility state in the same ways WK2 does. This involves
      listening for some new NSWindow delegates.
      
      Tools:
      
      Add a test that PageVisibility of WK1 WebViews and WK2 WKViews
      automatically changes between hidden and visible as the view is added
      and removed from window, or when it is in a window that changes
      visibility, for instance by minimizing / deminimizing.
      
      Reviewed by NOBODY (OOPS!).
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/mac/PageVisibilityStateWithWindowChanges.html: Added.
      * TestWebKitAPI/Tests/mac/PageVisibilityStateWithWindowChanges.mm: Added.
      (-[PageVisibilityStateDelegate webView:runJavaScriptAlertPanelWithMessage:initiatedByFrame:]):
      (runJavaScriptAlert):
      (PageVisibilityStateWithWindowChanges):
      (TestWebKitAPI::PageVisibilityStateWithWindowChanges::initializeView):
      (TestWebKitAPI::PageVisibilityStateWithWindowChanges::deinitializeView):
      (TestWebKitAPI::PageVisibilityStateWithWindowChanges::runTest):
      (TestWebKitAPI::TEST_F):
      Test visibility state of a page in a WebView/WKView with different window states.
      
      * TestWebKitAPI/mac/WebKitAgnosticTest.h:
      * TestWebKitAPI/mac/WebKitAgnosticTest.mm:
      (TestWebKitAPI::WebKitAgnosticTest::deinitializeView):
      (TestWebKitAPI::WebKitAgnosticTest::runWebKit1Test):
      (TestWebKitAPI::WebKitAgnosticTest::runWebKit2Test):
      Add a WK1 and WK2 deinitializeView to balance initializeView.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141011 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2152e36f
    • joepeck@webkit.org's avatar
      Improve PageVisibility API with enums · 5fd52db0
      joepeck@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=107364
      
      Reviewed by Sam Weinig.
      
      Source/WebKit/mac:
      
      * WebView/WebView.mm:
      * WebView/WebViewPrivate.h:
      (corePageVisibilityState):
      (-[WebView _setVisibilityState:isInitialState:]):
      Switch the private API form int to a WebPageVisibilityState enum.
      
      Source/WebKit2:
      
      * Shared/API/c/WKPageVisibilityTypes.h: Added.
      * Shared/API/c/WKSharedAPICast.h:
      (WebKit::toPageVisibilityState):
      Create an enum for page visibility APIs and a conversion function
      for the WK2 values to WebCore values.
      
      * Target.pri:
      * GNUmakefile.list.am:
      * WebKit2.xcodeproj/project.pbxproj:
      Add WKPageVisibilityTypes.h to the build as a private export.
      
      * UIProcess/API/C/WKPage.h:
      * UIProcess/API/C/WKPage.cpp:
      (WKPageSetVisibilityState):
      * UIProcess/WebPageProxy.h:
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::setVisibilityState):
      UIProcess API to set visibility state. WebPageProxy already
      had m_visibilityState, so update that when setter is used.
      
      * WebProcess/InjectedBundle/API/c/WKBundle.cpp:
      * WebProcess/InjectedBundle/API/c/WKBundlePrivate.h:
      * WebProcess/InjectedBundle/InjectedBundle.cpp:
      * WebProcess/InjectedBundle/InjectedBundle.h:
      Remove the old SPI for WebKitTestRunner. Tests now use the C API.
      
      * WebProcess/WebPage/WebPage.h:
      * WebProcess/WebPage/WebPage.cpp:
      (WebKit::WebPage::setVisibilityState):
      * WebProcess/WebPage/WebPage.messages.in:
      Update the existing WebPage API to use uint32_t, which matches
      other enum message types.
      
      Tools:
      
      * DumpRenderTree/mac/TestRunnerMac.mm:
      (TestRunner::resetPageVisibility):
      (TestRunner::setPageVisibility):
      Update the WK1 test code to use the new WK1 enums.
      
      * WebKitTestRunner/InjectedBundle/InjectedBundle.cpp:
      (WTR::InjectedBundle::setVisibilityState):
      * WebKitTestRunner/InjectedBundle/InjectedBundle.h:
      (InjectedBundle):
      * WebKitTestRunner/InjectedBundle/TestRunner.cpp:
      (WTR::TestRunner::setPageVisibility):
      (WTR::TestRunner::resetPageVisibility):
      * WebKitTestRunner/TestController.cpp:
      (WTR::TestController::setVisibilityState):
      * WebKitTestRunner/TestController.h:
      (TestController):
      * WebKitTestRunner/TestInvocation.cpp:
      (WTR::TestInvocation::didReceiveMessageFromInjectedBundle):
      Update the WK2 test code to use the new WK2 API and enums.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/PageVisibilityState.cpp: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::setPageVisibilityStateWithEvalContinuation):
      (TestWebKitAPI::assertSerializedScriptValueIsStringValue):
      (TestWebKitAPI::didRunStep1StateChangeVisibleToHidden):
      (TestWebKitAPI::didRunStep2StateChangeHiddenToPrerender):
      (TestWebKitAPI::didRunStep3StateChangePrerenderToPreview):
      (TestWebKitAPI::didRunStep4InStatePreview):
      (TestWebKitAPI::TEST):
      Test the new WK2 API with all enum types.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@141010 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5fd52db0
  29. 15 Jan, 2013 1 commit
    • enrica@apple.com's avatar
      Add a new set of WebKit2 APIs for text search and · ebd80c2b
      enrica@apple.com authored
      search results management.
      https://bugs.webkit.org/show_bug.cgi?id=106834.
      <rdar://problem/12597159>
      
      Source/WebCore: 
      
      Reviewed by Simon Fraser.
              
      Adding new API to perform text search in WebKit2 without using
      the stock UI. The new interface provides all the information
      necessary to write a custom UI for search.
      
      Added new TextWebKitAPI test.
      
      * WebCore.exp.in: Added new exported methods.
      * editing/Editor.cpp:
      (WebCore::Editor::countMatchesForText): Added new parameter to store
      all the ranges relative to the matches found.
      * editing/Editor.h: Modified the interface of countMatchesForText and removed
      the other definition of countMatchesForText with a different signature.
      * page/Page.cpp:
      (WebCore::Page::findStringMatchingRanges): Added.
      (WebCore::Page::markAllMatchesForText): Changed to use the new unified
      countMatchesForText.
      * page/Page.h:
      
      Source/WebKit/mac: 
      
      Reviewed by Simon Fraser.
              
      Adding new API to perform text search in WebKit2 without using
      the stock UI. The new interface provides all the information
      necessary to write a custom UI for search.
      
      Added new TextWebKitAPI test.
      
      * WebView/WebHTMLView.mm:
      (-[WebHTMLView countMatchesForText:inDOMRange:options:limit:markMatches:]):
      Modified to reflect the changes to Editor::countMatchesForText interface.
      
      Source/WebKit2: 
      
      Reviewed by Simon Fraser.
              
      Adding new API to perform text search in WebKit2 without using
      the stock UI. The new interface provides all the information
      necessary to write a custom UI for search. The main logic is
      implemented in the new functions added to FindController.
      
      Added new TextWebKitAPI test.
      
      * UIProcess/API/C/WKPage.cpp:
      (WKPageFindStringMatches): Added.
      (WKPageGetImageForFindMatch): Added.
      (WKPageSelectFindMatch): Added.
      (WKPageSetPageFindMatchesClient): Added.
      * UIProcess/API/C/WKPage.h: Added the new API definitions.
      * UIProcess/WebFindClient.cpp: Added new client callbacks.
      (WebKit::WebFindMatchesClient::didFindStringMatches):
      (WebKit::WebFindMatchesClient::didGetImageForMatchResult):
      * UIProcess/WebFindClient.h:
      (WebFindMatchesClient): Added.
      * UIProcess/WebPageProxy.cpp: Added proxy methods.
      (WebKit::WebPageProxy::initializeFindMatchesClient):
      (WebKit::WebPageProxy::findStringMatches):
      (WebKit::WebPageProxy::getImageForFindMatch):
      (WebKit::WebPageProxy::selectFindMatch):
      (WebKit::WebPageProxy::didGetImageForFindMatch):
      (WebKit::WebPageProxy::didFindStringMatches):
      * UIProcess/WebPageProxy.h:
      * UIProcess/WebPageProxy.messages.in:
      * WebProcess/WebPage/FindController.cpp:
      (WebKit::FindController::findStringMatches): Finds all the matching
      text according to the find options. All the matching text ranges are
      stored in a vector until the next call to findStringMatches or until
      hideFindUI is called. The message that is sent back to the UI process
      contains a vector containing an entry for each find match (i.e. for each
      range) and each entry is represented by a vector of the corresponding
      text rects. It also returns the index in the vector of matches corresponding
      to the first match after the user selection.
      If there is no selection the index is always 0 and if there are no
      matches after the user selection, the index returned is -1.
      (WebKit::FindController::getFindIndicatorBitmapAndRect): Helper function
      to share code between updateFindIndicator and getImageForFindMatch.
      (WebKit::FindController::getImageForFindMatch): Creates the image corresponding
      to the text matched at the given match index.
      (WebKit::FindController::selectFindMatch): creates a selection for the range
      corresponding to the given match index.
      (WebKit::FindController::hideFindUI): Added logic to clear the vector
      of matched ranges.
      (WebKit::FindController::updateFindIndicator): Updated to use the
      new helper function getFindIndicatorBitmapAndRect.
      * WebProcess/WebPage/FindController.h:
      * WebProcess/WebPage/WebPage.cpp:
      (WebKit::WebPage::findStringMatches):
      (WebKit::WebPage::getImageForFindMatch):
      (WebKit::WebPage::selectFindMatch):
      * WebProcess/WebPage/WebPage.h:
      * WebProcess/WebPage/WebPage.messages.in:
      
      Tools: 
      
      Added new test for the new WebKit2 API for
      text search.
              
      Reviewed by Simon Fraser.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebKit2/FindMatches.mm: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139796 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ebd80c2b
  30. 07 Jan, 2013 2 commits
    • rniwa@webkit.org's avatar
      Source/JavaScriptCore: Sorted the xcodeproj file. · 657d387a
      rniwa@webkit.org authored
      * JavaScriptCore.xcodeproj/project.pbxproj:
      
      Tools: Sorted more xcodeproj files.
      
      * MiniBrowser/MiniBrowser.xcodeproj/project.pbxproj:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * WebKitLauncher/WebKitLauncher.xcodeproj/project.pbxproj:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139012 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      657d387a
    • mitz@apple.com's avatar
      [mac] WebKit1 clients can’t tell when a frame has been removed from the hierarchy · ae97f6dd
      mitz@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106261
      
      Reviewed by Simon Fraser.
      
      Source/WebKit/mac: 
      
      Test: TestWebKitAPI/Tests/mac/WebViewDidRemoveFrameFromHierarchy.mm.
      
      Added -[WebFrameLoadDelegate webView:didRemoveFrameFromHierarchy:].
      
      * WebCoreSupport/WebFrameLoaderClient.mm:
      (WebFrameLoaderClient::detachedFromParent2): Added a call to the new frame load delegate
      method.
      * WebView/WebDelegateImplementationCaching.h:
      (WebFrameLoadDelegateImplementationCache): Added the new method to the cache.
      * WebView/WebFrameLoadDelegatePrivate.h: Declared the new delegate method.
      * WebView/WebView.mm:
      (-[WebView _cacheFrameLoadDelegateImplementations]): Added the new method to the cache.
      
      Tools: 
      
      Added a test for -[WebFrameLoadDelegate webView:didRemoveFrameFromHierarchy:].
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/mac/WebViewDidRemoveFrameFromHierarchy.mm: Added.
      (-[DidRemoveFrameFromHierarchyFrameLoadDelegate webView:didFinishLoadForFrame:]):
      (-[DidRemoveFrameFromHierarchyFrameLoadDelegate webView:didRemoveFrameFromHierarchy:]):
      (TestWebKitAPI):
      (TestWebKitAPI::TEST):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139000 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ae97f6dd
  31. 04 Jan, 2013 1 commit
  32. 03 Jan, 2013 1 commit
    • mitz@apple.com's avatar
      No way to obtain a DOMNode given a JS wrapper for a Node · 79076e69
      mitz@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106033
      
      Source/WebCore: 
      
      Reviewed by Sam Weinig.
      
      Test: TestWebKitAPI/Tests/mac/DOMNodeFromJSObject.mm.
      
      * bindings/objc/DOM.mm:
      (+[DOMNode _nodeFromJSWrapper:]): Added. If the given JSObjectRef is a wrapper for a Node,
      returns the Objective-C wrapper for that node. Note that Objective-C wrappers are always
      for the main world, regardless of which world the given JS wrapper comes from.
      * bindings/objc/DOMPrivate.h: Added declaration of the above.
      
      Tools: 
      
      Added a test for +[DOMNode _nodeFromJSWrapper:].
      
      Reviewed by Sam Weinig.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/mac/DOMNodeFromJSObject.mm: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::TEST):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138747 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      79076e69
  33. 18 Dec, 2012 2 commits
    • alice.liu@apple.com's avatar
      Source/WebKit/mac: Add SPI to WebKit1 WebFrame for hit testing · c2377217
      alice.liu@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105106
      
      Reviewed by Dan Bernstein.
      
      * WebView/WebFrame.mm:
      (-[WebFrame elementAtPoint:]): Added. Takes an NSPoint to feed to the WebCore::Frame for hit-testing.
      Creates a WebElementDictionary from that WebCore::HitTestResult, and returns the element dictionary. 
      * WebView/WebFramePrivate.h:
      
      Tools: Test for https://bugs.webkit.org/show_bug.cgi?id=105106
      Add SPI to WebKit1 WebFrame for hit testing
      
      Reviewed by Dan Bernstein.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: Added file Tests/mac/ElementAtPointInWebFrame.mm
      * TestWebKitAPI/Tests/mac/ElementAtPointInWebFrame.mm: Added.
      (TestWebKitAPI::TEST): Loads html with two divs positioned in the 2nd and 4th quadrants of the webview.
      Then hit-tests at three points, expecting to hit the two divs and body element. 
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138104 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c2377217
    • alice.liu@apple.com's avatar
      Source/WebKit/mac: Add SPI to WebKit1 WebFrame for node conversion to JSValueRef · 15b028de
      alice.liu@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=105262
      
      Reviewed by Anders Carlsson.
      
      * WebView/WebFrame.mm:
      (-[WebFrame jsWrapper:forWorld:]): Added. Takes a DOMNode and WebScriptWorld and provides a JSValueRef
      for the WebCore::Node in that particular WebScriptWorld.
      * WebView/WebFramePrivate.h:
      
      Tools: Test for https://bugs.webkit.org/show_bug.cgi?id=105262
      Add SPI to WebKit1 WebFrame for node conversion to JSValueRef
      
      Reviewed by Anders Carlsson.
      
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj: Added file Tests/mac/JSWrapperForNodeInWebFrame.mm.mm
      * TestWebKitAPI/Tests/mac/JSWrapperForNodeInWebFrame.mm.mm: Added.
      (TestWebKitAPI::TEST): Tests for the correct JS wrapper for a DOMNode, provided a WebScriptWorld.
      Loads html with a single div element. In an isolated world, creates a property on that node.
      Also, in the standard world, creates a different property on that node.  Then tests for 4 things:
          - Existence of the isolated property in the isolated world.
          - Existence of the standard property in the standard world.
          - Non-existence of the isolated property in the standard world.
          - Non-existence of the standard property in the isolated world.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138101 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      15b028de
  34. 17 Dec, 2012 1 commit
    • eae@chromium.org's avatar
      Clamp values in LayoutUnit::operator/ when SATURATED_LAYOUT_ARITHMETIC is enabled · 8dfcf073
      eae@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=104955
      
      Reviewed by Julien Chaffraix.
      
      Source/WebCore: 
      
      LayoutUnit::operator/ currently does not clamp values and
      instead overflows when given a value greater than INT_MAX or
      less than INT_MIN. 
      
      Test: TestWebKitAPI/Tests/WebCore/LayoutUnit.cpp
      
      * platform/LayoutUnit.h:
      (WebCore::operator/):
      Clamp value if SATURATED_LAYOUT_ARITHMETIC is enabled.
      
      Tools: 
      
      Add tests for LayoutUnit.
      
      * TestWebKitAPI/CMakeLists.txt:
      * TestWebKitAPI/ForwardingHeaders: Added.
      * TestWebKitAPI/ForwardingHeaders/WebCore: Added.
      * TestWebKitAPI/ForwardingHeaders/WebCore/LayoutUnit.h: Added.
      * TestWebKitAPI/TestWebKitAPI.gyp/TestWebKitAPI.gyp:
      * TestWebKitAPI/TestWebKitAPI.gypi:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * TestWebKitAPI/Tests/WebCore/LayoutUnit.cpp: Added.
      (TestWebKitAPI):
      (TestWebKitAPI::TEST):
      * TestWebKitAPI/win/TestWebKitAPI.vcproj:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@137924 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8dfcf073