1. 13 Jan, 2011 2 commits
    • enrica@apple.com's avatar
      Source/WebCore: WebKit2: Add support for drag and drop · 9d9813d0
      enrica@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=52343
      <rdar://problem/7660558>
                     
      Reviewed by Darin Adler.
      
      This patch contains the changes required to support dropping content
      in WebKit on the Mac. The DragData class has been extended to provide
      additional context from the application (keyboard state, modal windows, etc.)
      as well as information of the drag pasteboard being used.
      The support for WebKit as drag source will be added with a separate patch.
      
      * WebCore.exp.in:
      * page/DragController.cpp:
      (WebCore::DragController::dragIsMove): Added DragData parameter.
      (WebCore::DragController::tryDocumentDrag): Modified call to dragIsMove.
      (WebCore::DragController::concludeEditDrag): Same as above.
      * page/DragController.h: Added parameter to isCopyKeyDown.
      * page/mac/DragControllerMac.mm:
      The following methods have been modified to use the information stored
      in the DragData class.
      (WebCore::DragController::isCopyKeyDown):
      (WebCore::DragController::dragOperation):
      * platform/DragData.h:
      (WebCore::DragData::flags):
      * platform/DragData.cpp: Added default flags parameter to the constructor.
      * platform/mac/DragDataMac.mm:
      (WebCore::DragData::DragData): Added constructor that receives the name of the pasteboard to use.
      (WebCore::DragData::canSmartReplace):
      (WebCore::DragData::containsColor):
      (WebCore::DragData::containsFiles):
      (WebCore::DragData::asFilenames):
      (WebCore::DragData::containsPlainText):
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsCompatibleContent):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asFragment):
      All the following files have been modified to add the DragData
      parameter to isCopyKeyDown. I plan to improve this in the future
      and make isCopyKeyDown not platform specific.
      * page/android/DragControllerAndroid.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/brew/DragControllerBrew.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/chromium/DragControllerChromium.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/efl/DragControllerEfl.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/gtk/DragControllerGtk.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/haiku/DragControllerHaiku.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/mac/DragControllerMac.mm:
      (WebCore::DragController::isCopyKeyDown):
      (WebCore::DragController::dragOperation):
      * page/qt/DragControllerQt.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/win/DragControllerWin.cpp:
      (WebCore::DragController::isCopyKeyDown):
      * page/wx/DragControllerWx.cpp:
      (WebCore::DragController::isCopyKeyDown):
      
      WebKit/mac: WebKit2: Add support for drag and drop
      https://bugs.webkit.org/show_bug.cgi?id=52343
      <rdar://problem/7660558>
              
      Reviewed by Darin Adler.
      
      The DragData class has been extended to provide
      additional context from the application (keyboard state, modal windows, etc.)
      as well as information of the drag pasteboard being used.
      These are the changes to align the behavior for WebKit.
      
      * WebView/WebView.mm:
      (-[WebView applicationFlags:]): Added.
      (-[WebView draggingEntered:]): Added parameter to the DragData constructor.
      (-[WebView draggingUpdated:]): Added parameter to the DragData constructor.
      (-[WebView draggingExited:]): Added parameter to the DragData constructor.
      (-[WebView performDragOperation:]): Added parameter to the DragData constructor.
      
      WebKit2: WebKit2: Add support for drag and drop
      https://bugs.webkit.org/show_bug.cgi?id=52343
      <rdar://problem/7660558>
                     
      Reviewed by Darin Adler.
      
      This patch contains the changes required to support dropping content
      in WebKit on the Mac. The DragData class has been extended to provide
      additional context from the application (keyboard state, modal windows, etc.)
      as well as information of the drag pasteboard being used.
      The support for WebKit as drag source will be added with a separate patch.
      
      * Shared/DragControllerAction.h: Added.
      * UIProcess/API/mac/WKView.mm:
      Added implemention of the methods required to add suport for a drop target.
      To maintain asynchronous communication with the WebProcess, we always return
      the previous calculated value for the drag operation.
      (-[WKView _registerDraggedTypes]):
      (-[WKView initWithFrame:contextRef:pageGroupRef:]):
      (-[WKView applicationFlags:]):
      (-[WKView draggingEntered:]):
      (-[WKView draggingUpdated:]):
      (-[WKView draggingExited:]):
      (-[WKView prepareForDragOperation:]):
      (-[WKView performDragOperation:]):
      * UIProcess/WebPageProxy.cpp:
      (WebKit::WebPageProxy::WebPageProxy):
      (WebKit::WebPageProxy::performDragControllerAction):
      (WebKit::WebPageProxy::didPerformDragControllerAction):
      * UIProcess/WebPageProxy.h:
      (WebKit::WebPageProxy::dragOperation):
      (WebKit::WebPageProxy::resetDragOperation):
      * UIProcess/WebPageProxy.messages.in:
      * WebKit2.xcodeproj/project.pbxproj:
      * WebProcess/WebCoreSupport/WebDragClient.cpp:
      (WebKit::WebDragClient::willPerformDragDestinationAction):
      (WebKit::WebDragClient::willPerformDragSourceAction):
      (WebKit::WebDragClient::actionMaskForDrag):
      (WebKit::WebDragClient::dragSourceActionMaskForPoint):
      (WebKit::WebDragClient::startDrag):
      * WebProcess/WebPage/WebPage.cpp:
      (WebKit::WebPage::performDragControllerAction):
      * WebProcess/WebPage/WebPage.h:
      * WebProcess/WebPage/WebPage.messages.in:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75743 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9d9813d0
    • jianli@chromium.org's avatar
      Change createObjectURL and revokeObjectURL to put under webkitURL. · 1c19f401
      jianli@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=52257
      
      Reviewed by Darin Fisher.
      
      Source/WebCore:
      
      Note that we add "webkit" vendor prefix to URL that is introduced in
      the latest File API spec.
      
      For the time being, we implement webkitURL as a readonly attribute
      instead of a constructor so that we will not expose prototype property,
      as required by the spec.
      
      * Android.derived.jscbindings.mk:
      * Android.derived.v8bindings.mk:
      * Android.mk:
      * CMakeLists.txt:
      * DerivedSources.cpp:
      * DerivedSources.make:
      * GNUmakefile.am:
      * WebCore.gypi:
      * WebCore.pri:
      * WebCore.pro:
      * WebCore.vcproj/WebCore.vcproj:
      * WebCore.xcodeproj/project.pbxproj:
      * html/DOMURL.cpp: Added.
      * html/DOMURL.h: Added.
      * html/DOMURL.idl: Added.
      * inspector/front-end/NetworkPanel.js:
      * inspector/front-end/utilities.js:
      * page/DOMWindow.cpp:
      (WebCore::DOMWindow::webkitURL):
      * page/DOMWindow.h:
      * page/DOMWindow.idl:
      * workers/WorkerContext.cpp:
      (WebCore::WorkerContext::webkitURL):
      * workers/WorkerContext.h:
      * workers/WorkerContext.idl:
      
      LayoutTests:
      
      Change all related test scripts and results to account for this change.
      
      * fast/dom/Window/script-tests/window-property-descriptors.js:
      * fast/dom/Window/window-properties-expected.txt:
      * fast/dom/Window/window-properties.html:
      * fast/dom/script-tests/prototype-inheritance-2.js:
      * fast/dom/script-tests/prototype-inheritance.js:
      * fast/files/apply-blob-url-to-img.html:
      * fast/files/apply-blob-url-to-xhr.html:
      * fast/files/create-blob-url-crash.html:
      * fast/files/revoke-blob-url.html:
      * fast/files/workers/resources/worker-apply-blob-url-to-xhr.js:
      (onmessage):
      * platform/qt/fast/dom/Window/window-properties-expected.txt:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75739 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1c19f401
  2. 12 Jan, 2011 3 commits
    • cmarrin@apple.com's avatar
      2011-01-12 Chris Marrin <cmarrin@apple.com> · ef189c6b
      cmarrin@apple.com authored
              Unreviewed.
      
              Fix for Gtk and Windows builds
      
              * page/Frame.cpp:
              (WebCore::Frame::scalePage):
              * page/Frame.h:
              * platform/graphics/ca/win/PlatformCALayerWin.cpp:
              (PlatformCALayer::contentsScale):
              (PlatformCALayer::setContentsScale):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75652 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ef189c6b
    • cmarrin@apple.com's avatar
      2011-01-12 Chris Marrin <cmarrin@apple.com> · 09f22bf4
      cmarrin@apple.com authored
              Reviewed by Simon Fraser.
              
              Pages with accelerated layers lose subpixel-AA and become blurry when a scale factor is applied
              rdar://problem/8824974
      
              When scaled, WebKit renders the page content at the scaled up size, so there are no
              scaling artifacts. But content drawn into a layer's backing store does not scale up.
              This is made worse by the fact that the root page contents become layered when there
              are other accelerated compositing layers present (video, plugins, etc.).
              
              Plumb scaling factor from Frame::scalePage() down into all layers with content. It
              eventually calls CALayer::setContentsScale which renders to a backing store whose dimensions
              are scaled, causing them to render larger and appear pixel perfect at the scaled
              page size.
       
               * page/Frame.cpp:
               (WebCore::Frame::updateContentsScale):
               (WebCore::Frame::scalePage):
               * page/Frame.h:
               * platform/graphics/GraphicsLayer.h:
               * platform/graphics/ca/GraphicsLayerCA.cpp:
               (WebCore::GraphicsLayerCA::setContentsScale):
               (WebCore::GraphicsLayerCA::clampedContentsScaleForScale):
               * platform/graphics/ca/GraphicsLayerCA.h:
               (WebCore::GraphicsLayerCA::contentsScale):
               * platform/graphics/ca/PlatformCALayer.h:
               * platform/graphics/ca/mac/PlatformCALayerMac.mm:
               (PlatformCALayer::contentsScale):
               (PlatformCALayer::setContentsScale):
               * rendering/RenderLayer.cpp:
               (WebCore::RenderLayer::updateContentsScale):
               * rendering/RenderLayer.h:
               * rendering/RenderLayerBacking.cpp:
               (WebCore::RenderLayerBacking::createGraphicsLayer):
               (WebCore::RenderLayerBacking::updateForegroundLayer):
               (WebCore::RenderLayerBacking::updateMaskLayer):
               (WebCore::RenderLayerBacking::updateContentsScale):
               * rendering/RenderLayerBacking.h:
               * rendering/RenderLayerCompositor.cpp:
               (WebCore::RenderLayerCompositor::updateContentsScale):
               * rendering/RenderLayerCompositor.h:
       
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75639 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      09f22bf4
    • yurys@chromium.org's avatar
      2010-12-29 Yury Semikhatsky <yurys@chromium.org> · 389a6246
      yurys@chromium.org authored
              Reviewed by Pavel Feldman.
      
              inspector/timeline-network-resource.html fails when run twice
              https://bugs.webkit.org/show_bug.cgi?id=37394
      
              Send didReceiveResponse notification to the timeline agent from ResourceLoadNotifier
              instead of ResourceLoader::didReceiveResponse to cover the cases when resources
              are loaded from memory cache.
      
              Network notifications are now send to InspectorInstrumentation which dispatches
              them to interested agents and InspectorController.
              fix
      
              * inspector/timeline-network-resource-expected.txt:
              * inspector/timeline-network-resource.html:
              * inspector/timeline-network-resource.js:
      2010-12-29  Yury Semikhatsky  <yurys@chromium.org>
      
              Reviewed by Pavel Feldman.
      
              inspector/timeline-network-resource.html fails when run twice
              https://bugs.webkit.org/show_bug.cgi?id=37394
      
              Send didReceiveResponse notification to the timeline agent from ResourceLoadNotifier
              instead of ResourceLoader::didReceiveResponse to cover the cases when resources
              are loaded from memory cache.
      
              Network notifications are now sent to InspectorInstrumentation which dispatches
              them to interested agents and InspectorController.
      
              * inspector/Inspector.idl:
              * inspector/InspectorApplicationCacheAgent.cpp:
              (WebCore::InspectorApplicationCacheAgent::didReceiveManifestResponse):
              * inspector/InspectorController.cpp:
              (WebCore::InspectorController::InspectorController):
              (WebCore::InspectorController::didCommitLoad):
              (WebCore::InspectorController::willSendRequest):
              (WebCore::InspectorController::didReceiveResponse):
              (WebCore::InspectorController::didFailLoading):
              (WebCore::InspectorController::resourceRetrievedByXMLHttpRequest):
              * inspector/InspectorController.h:
              * inspector/InspectorInstrumentation.cpp:
              (WebCore::InspectorInstrumentation::identifierForInitialRequestImpl):
              (WebCore::InspectorInstrumentation::willSendRequestImpl):
              (WebCore::InspectorInstrumentation::markResourceAsCachedImpl):
              (WebCore::InspectorInstrumentation::didLoadResourceFromMemoryCacheImpl):
              (WebCore::InspectorInstrumentation::willReceiveResourceResponseImpl):
              (WebCore::InspectorInstrumentation::didReceiveContentLengthImpl):
              (WebCore::InspectorInstrumentation::didFinishLoadingImpl):
              (WebCore::InspectorInstrumentation::didFailLoadingImpl):
              (WebCore::InspectorInstrumentation::resourceRetrievedByXMLHttpRequestImpl):
              (WebCore::InspectorInstrumentation::scriptImportedImpl):
              (WebCore::InspectorInstrumentation::retrieveResourceAgent):
              * inspector/InspectorInstrumentation.h:
              (WebCore::InspectorInstrumentation::identifierForInitialRequest):
              (WebCore::InspectorInstrumentation::willSendRequest):
              (WebCore::InspectorInstrumentation::markResourceAsCached):
              (WebCore::InspectorInstrumentation::didLoadResourceFromMemoryCache):
              (WebCore::InspectorInstrumentation::willReceiveResourceResponse):
              (WebCore::InspectorInstrumentation::didReceiveContentLength):
              (WebCore::InspectorInstrumentation::didFinishLoading):
              (WebCore::InspectorInstrumentation::didFailLoading):
              (WebCore::InspectorInstrumentation::resourceRetrievedByXMLHttpRequest):
              (WebCore::InspectorInstrumentation::scriptImported):
              * inspector/InspectorResourceAgent.cpp:
              (WebCore::InspectorResourceAgent::identifierForInitialRequest):
              * inspector/InspectorResourceAgent.h:
              * inspector/InspectorTimelineAgent.cpp:
              (WebCore::InspectorTimelineAgent::willSendResourceRequest):
              * inspector/InspectorTimelineAgent.h:
              * inspector/TimelineRecordFactory.cpp:
              (WebCore::TimelineRecordFactory::createResourceSendRequestData):
              * inspector/TimelineRecordFactory.h:
              * inspector/front-end/NetworkManager.js:
              (WebInspector.NetworkManager.prototype.identifierForInitialRequest):
              * inspector/front-end/TimelinePanel.js:
              (WebInspector.TimelinePanel.prototype.addRecordToTimeline):
              * loader/FrameLoader.cpp:
              (WebCore::FrameLoader::loadedResourceFromMemoryCache):
              * loader/ResourceLoadNotifier.cpp:
              (WebCore::ResourceLoadNotifier::didReceiveResponse):
              (WebCore::ResourceLoadNotifier::didFailToLoad):
              (WebCore::ResourceLoadNotifier::assignIdentifierToInitialRequest):
              (WebCore::ResourceLoadNotifier::dispatchWillSendRequest):
              (WebCore::ResourceLoadNotifier::dispatchDidReceiveResponse):
              (WebCore::ResourceLoadNotifier::dispatchDidReceiveContentLength):
              (WebCore::ResourceLoadNotifier::dispatchDidFinishLoading):
              (WebCore::ResourceLoadNotifier::sendRemainingDelegateMessages):
              * loader/ResourceLoader.cpp:
              (WebCore::ResourceLoader::didReceiveResponse):
              * loader/appcache/ApplicationCacheGroup.cpp:
              (WebCore::ApplicationCacheGroup::createResourceHandle):
              (WebCore::ApplicationCacheGroup::didReceiveResponse):
              (WebCore::ApplicationCacheGroup::didReceiveData):
              (WebCore::ApplicationCacheGroup::didFinishLoading):
              (WebCore::ApplicationCacheGroup::didFail):
              * loader/appcache/ApplicationCacheGroup.h:
              * workers/DefaultSharedWorkerRepository.cpp:
              (WebCore::SharedWorkerScriptLoader::notifyFinished):
              * workers/Worker.cpp:
              (WebCore::Worker::notifyFinished):
              * workers/WorkerContext.cpp:
              (WebCore::WorkerContext::importScripts):
              * xml/XMLHttpRequest.cpp:
              (WebCore::XMLHttpRequest::didFinishLoading):
      2010-12-29  Yury Semikhatsky  <yurys@chromium.org>
      
              Reviewed by Pavel Feldman.
      
              inspector/timeline-network-resource.html fails when run twice
              https://bugs.webkit.org/show_bug.cgi?id=37394
      
              Send didReceiveResponse notification to the timeline agent from ResourceLoadNotifier
              instead of ResourceLoader::didReceiveResponse to cover the cases when resources
              are loaded from memory cache.
      
              Network notifications are now sent to InspectorInstrumentation which dispatches
              them to interested agents and InspectorController.
      
              * src/SharedWorkerRepository.cpp:
              (WebCore::SharedWorkerScriptLoader::notifyFinished):
              * src/WebDevToolsAgentImpl.cpp:
              (WebKit::WebDevToolsAgentImpl::mainFrame):
              (WebKit::WebDevToolsAgentImpl::identifierForInitialRequest):
              (WebKit::WebDevToolsAgentImpl::willSendRequest):
              (WebKit::WebDevToolsAgentImpl::didReceiveData):
              (WebKit::WebDevToolsAgentImpl::didReceiveResponse):
              (WebKit::WebDevToolsAgentImpl::didFinishLoading):
              (WebKit::WebDevToolsAgentImpl::didFailLoading):
              * src/WebDevToolsAgentImpl.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75604 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      389a6246
  3. 11 Jan, 2011 5 commits
    • simonjam@chromium.org's avatar
      2011-01-11 James Simonsen <simonjam@chromium.org> · 4648b7c3
      simonjam@chromium.org authored
              Reviewed by Eric Seidel.
      
              [Web Timing] Rename sslHandshakeStart to secureConnectionStart
              https://bugs.webkit.org/show_bug.cgi?id=52239
      
              * fast/dom/Window/window-properties-performance-expected.txt:
              * fast/dom/script-tests/webtiming.js:
              (checkTimingBeforeLoad):
              (checkTimingWhileDeferred):
              (checkWebTimingOnDOMContentLoaded):
              (checkWebTimingWhileAsync):
              (checkWebTimingOnLoad):
              (checkWebTimingAfterLoad):
              * fast/dom/webtiming-document-open-expected.txt:
              * fast/dom/webtiming-expected.txt:
              * fast/dom/webtiming-navigate-within-document-expected.txt:
              * http/tests/misc/resources/webtiming-cross-origin-and-back2.html:
              * http/tests/misc/resources/webtiming-cross-origin-redirect.html:
              * http/tests/misc/resources/webtiming-no-origin.html:
              * http/tests/misc/resources/webtiming-ssl.html:
              * http/tests/misc/webtiming-origins-expected.txt:
              * http/tests/misc/webtiming-ssl-expected.txt:
      2011-01-11  James Simonsen  <simonjam@chromium.org>
      
              Reviewed by Eric Seidel.
      
              [Web Timing] Rename sslHandshakeStart to secureConnectionStart
              https://bugs.webkit.org/show_bug.cgi?id=52239
      
              * page/PerformanceTiming.cpp:
              (WebCore::PerformanceTiming::secureConnectionStart):
              * page/PerformanceTiming.h:
              * page/PerformanceTiming.idl:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75560 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4648b7c3
    • abarth@webkit.org's avatar
      2011-01-11 Adam Barth <abarth@webkit.org> · 75a12a2b
      abarth@webkit.org authored
              Reviewed by Eric Seidel.
      
              Introduce the notion of a "display-isolated" URL scheme for use by
              Chrome-internal URLs
              https://bugs.webkit.org/show_bug.cgi?id=50182
      
              This patch actually makes the display-isolated schemes display
              isolated.  The behavior should be the same as the previous iteration of
              this patch, but re-organized a bit because reading the access white
              list is expensive.
      
              * page/SecurityOrigin.cpp:
              (WebCore::SecurityOrigin::isAccessToURLWhiteListed):
              (WebCore::SecurityOrigin::canDisplay):
              * page/SecurityOrigin.h:
              * platform/SchemeRegistry.cpp:
              * platform/SchemeRegistry.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75557 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      75a12a2b
    • mihaip@chromium.org's avatar
      2011-01-11 Mihai Parparita <mihaip@chromium.org> · 5ed30ae1
      mihaip@chromium.org authored
              Reviewed by Darin Fisher.
      
              Scroll event should be fired asynchronously
              https://bugs.webkit.org/show_bug.cgi?id=45631
      
              Update existing tests that assumed that scroll events fired
              synchronously.
      
              * editing/input/page-up-down-scrolls-expected.txt:
              * editing/input/page-up-down-scrolls.html:
              * fast/events/fire-scroll-event-element-expected.txt: Copied from LayoutTests/fast/events/fire-scroll-event-expected.txt.
              * fast/events/fire-scroll-event-element.html: Added. Does the same
                  tests as fire-scroll-event.html, but on an individual element instead
                  of the whole document.
              * fast/events/fire-scroll-event-expected.txt:
              * fast/events/fire-scroll-event.html: Now explicitly tests for
                  synchronous behavior when scrolling the document, and that we don't
                  fire the event more than once.
              * fast/events/remove-child-onscroll.html:
              * fast/events/scroll-during-zoom-change.html:
              * fast/events/scroll-event-does-not-bubble.html:
              * fast/events/scroll-event-phase-expected.txt: Added.
              * fast/events/scroll-event-phase.html: Added. Checks that we can listen
                  for scroll events in both the capture and bubble phase.
              * fast/layers/removed-by-scroll-handler.html:
              * fast/overflow/onscroll-layer-self-destruct.html:
              * fast/repaint/repaint-during-scroll.html:
      2011-01-11  Mihai Parparita  <mihaip@chromium.org>
      
              Reviewed by Darin Fisher.
      
              Scroll event should be fired asynchronously
              https://bugs.webkit.org/show_bug.cgi?id=45631
      
              Tests: fast/events/fire-scroll-event.html
                     fast/events/fire-scroll-event-element.html
                     fast/events/scroll-event-phase.html
      
              Makes scroll events fire asynchronously to be in compliance with the
              CSSOM View Module and consistent with Gecko, Opera and (to some degree)
              IE.
      
              Implemented via the EventQueue class added by r74062 (EventQueue now
              has a convenience enqueueScrollEvent method).
      
              * dom/EventQueue.cpp:
              (WebCore::EventQueue::enqueueScrollEvent):
              (WebCore::EventQueue::pendingEventTimerFired):
              * dom/EventQueue.h:
              * page/EventHandler.cpp:
              (WebCore::EventHandler::sendScrollEvent):
              * rendering/RenderLayer.cpp:
              (WebCore::RenderLayer::scrollToOffset):
              * rendering/RenderListBox.cpp:
              (WebCore::RenderListBox::valueChanged):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75555 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5ed30ae1
    • inferno@chromium.org's avatar
      2011-01-11 Abhishek Arya <inferno@chromium.org> · acfd01cc
      inferno@chromium.org authored
              Reviewed by Dimitri Glazkov.
      
              RefPtr the FrameView to prevent scrollbar from getting deleted inside
              its scroll event.
              https://bugs.webkit.org/show_bug.cgi?id=52238
      
              Test: scrollbars/scrollable-iframe-remove-crash.html
      
              * page/DOMWindow.cpp:
              (WebCore::DOMWindow::scrollTo):
      2011-01-11  Abhishek Arya  <inferno@chromium.org>
      
              Reviewed by Dimitri Glazkov.
      
              Tests that we do not crash when we remove scrollable iframe when executing
              inside its scroll event.
              https://bugs.webkit.org/show_bug.cgi?id=52238
      
              * scrollbars/scrollable-iframe-remove-crash-expected.txt: Added.
              * scrollbars/scrollable-iframe-remove-crash.html: Added.
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75548 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      acfd01cc
    • enrica@apple.com's avatar
      Source/WebCore: Paste and drag and drop use different code paths to interact with the pasteboard. · 964ea218
      enrica@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=52093
      The change consists in a refactoring of the code to have only one class that
      deals with the pasteboard on Mac.
      
      Reviewed by Alexey Proskuryakov.
      
      No new tests. A test is already available for this
      (editing/pasteboard/drag-image-to-contenteditable-in-iframe.html) but had incorrect results.
      
      * WebCore.exp.in:
      * loader/EmptyClients.h: Added two Mac only methods to call into WebKit to use functionality
      that is in NSURLExtras.
      (WebCore::EmptyEditorClient::canonicalizeURL):
      (WebCore::EmptyEditorClient::canonicalizeURLString):
      * page/DragController.cpp:
      The following methods have been changed to pass a pointer to the Frame object
      to the DragData class.
      (WebCore::documentFragmentFromDragData):
      (WebCore::DragController::performDrag):
      (WebCore::DragController::dispatchTextInputEventFor):
      (WebCore::DragController::concludeEditDrag):
      * page/EditorClient.h: Added two Mac only methods to call into WebKit to use functionality
      that is in NSURLExtras.
      The following files have been modified to pass the Frame object to the DragData method calls.
      * page/chromium/DragControllerChromium.cpp:
      (WebCore::DragController::dragOperation):
      * page/gtk/DragControllerGtk.cpp:
      (WebCore::DragController::dragOperation):
      * page/mac/DragControllerMac.mm:
      (WebCore::DragController::dragOperation):
      * page/qt/DragControllerQt.cpp:
      (WebCore::DragController::dragOperation):
      * page/win/DragControllerWin.cpp:
      (WebCore::DragController::dragOperation):
      * platform/DragData.h: Removed Mac specific constructor and reference to PasteboardHelper class.
      * platform/Pasteboard.h: Added public constructor to create a Pasteboard object from an NSPasteboard.
      The following files were all modified to match the new parameters of the methods listed.
      * platform/android/DragDataAndroid.cpp:
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asFragment):
      * platform/chromium/DragDataChromium.cpp:
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsCompatibleContent):
      (WebCore::DragData::asFragment):
      * platform/gtk/DragDataGtk.cpp:
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsCompatibleContent):
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asFragment):
      * platform/haiku/DragDataHaiku.cpp:
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asFragment):
      * platform/mac/DragDataMac.mm:
      (WebCore::DragData::DragData):
      (WebCore::DragData::asPlainText):
      (WebCore::insertablePasteboardTypes):
      (WebCore::DragData::containsCompatibleContent):
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asFragment):
      * platform/mac/PasteboardMac.mm:
      (WebCore::Pasteboard::getBestURL):
      (WebCore::Pasteboard::asURL):
      * platform/qt/DragDataQt.cpp:
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsCompatibleContent):
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asFragment):
      * platform/win/DragDataWin.cpp:
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsCompatibleContent):
      (WebCore::DragData::asFragment):
      * platform/wince/DragDataWinCE.cpp:
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::asFragment):
      * platform/wx/DragDataWx.cpp:
      (WebCore::DragData::asPlainText):
      (WebCore::DragData::containsURL):
      (WebCore::DragData::asURL):
      (WebCore::DragData::asFragment):
      
      WebKit: Paste and drag and drop use different code paths to interact with the pasteboard.
      https://bugs.webkit.org/show_bug.cgi?id=52093
      The change consists in a refactoring of the code to have only one class that
      deals with the pasteboard on Mac.
      
      Reviewed by Alexey Proskuryakov.
      
      * WebKit.xcodeproj/project.pbxproj: Removed WebPasteboardHelper.mm and WebPasteboardHelper.h.
      
      WebKit/mac: Paste and drag and drop use different code paths to interact with the pasteboard.
      https://bugs.webkit.org/show_bug.cgi?id=52093
      The change consists in a refactoring of the code to have only one class that
      deals with the pasteboard on Mac.
      
      Reviewed by Alexey Proskuryakov.
      
      * WebCoreSupport/WebEditorClient.h:
      * WebCoreSupport/WebEditorClient.mm: Added two methods to provide to WebCore functionality
      exposed by NSURLExtras.
      (WebEditorClient::canonicalizeURL):
      (WebEditorClient::canonicalizeURLString):
      * WebCoreSupport/WebPasteboardHelper.h: Removed.
      * WebCoreSupport/WebPasteboardHelper.mm: Removed.
      * WebView/WebHTMLView.mm: Removed comment.
      * WebView/WebView.mm: The following methods have been changed to use the new DragData
      constructor that doesn't use the WebPasteboardHelper reference.
      (-[WebView draggingEntered:]):
      (-[WebView draggingUpdated:]):
      (-[WebView draggingExited:]):
      (-[WebView performDragOperation:]):
      
      WebKit2: Paste and drag and drop use different code paths to interact with the pasteboard.
      https://bugs.webkit.org/show_bug.cgi?id=52093
      The change consists in a refactoring of the code to have only one class that
      deals with the pasteboard on Mac.
      
      Reviewed by Alexey Proskuryakov.
      
      * WebProcess/WebCoreSupport/WebEditorClient.h:
      * WebProcess/WebCoreSupport/mac/WebEditorClientMac.mm: Added two methods to provide to WebCore functionality
      exposed by NSURLExtras.
      (WebKit::WebEditorClient::canonicalizeURL):
      (WebKit::WebEditorClient::canonicalizeURLString):
      
      LayoutTests: Paste and drag and drop use different code paths to interact with the pasteboard.
      https://bugs.webkit.org/show_bug.cgi?id=52093
      
      Reviewed by Alexey Proskuryakov.
      
      New test results added to match the correct behavior.
              
      * platform/mac/editing/pasteboard/drag-image-to-contenteditable-in-iframe-expected.checksum:
      * platform/mac/editing/pasteboard/drag-image-to-contenteditable-in-iframe-expected.png:
      * platform/mac/editing/pasteboard/drag-image-to-contenteditable-in-iframe-expected.txt:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75523 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      964ea218
  4. 10 Jan, 2011 2 commits
    • abarth@webkit.org's avatar
      2011-01-10 Adam Barth <abarth@webkit.org> · c655f688
      abarth@webkit.org authored
              Reviewed by Darin Adler.
      
              Introduce the notion of a "display-isolated" URL scheme for use by
              Chrome-internal URLs
              https://bugs.webkit.org/show_bug.cgi?id=50182
      
              This patch adds a Chromium API for registering schemes as
              display-isolated.  In a subsequent patch, I'll change the "chrome"
              scheme in Chrome to be display isolated instead of local.  That will
              prevent file URLs from linking to chrome URLs.
      
              * public/WebSecurityPolicy.h:
              * src/WebSecurityPolicy.cpp:
              (WebKit::WebSecurityPolicy::registerURLSchemeAsDisplayIsolated):
      2011-01-10  Adam Barth  <abarth@webkit.org>
      
              Reviewed by Darin Adler.
      
              Introduce the notion of a "display-isolated" URL scheme for use by
              Chrome-internal URLs
              https://bugs.webkit.org/show_bug.cgi?id=50182
      
              Update to new function name.
      
              * Api/qwebsecurityorigin.cpp:
              (QWebSecurityOrigin::localSchemes):
      2011-01-10  Adam Barth  <abarth@webkit.org>
      
              Reviewed by Darin Adler.
      
              Introduce the notion of a "display-isolated" URL scheme for use by
              Chrome-internal URLs
              https://bugs.webkit.org/show_bug.cgi?id=50182
      
              This patch adds the basic plumbing for display-isolated URL schemes.
              Originally, this patch also had the functional change, but I've split
              that off into a separate patch because the original patch caused a
              performance regression.
      
              * page/SecurityOrigin.cpp:
              (WebCore::SecurityOrigin::canDisplay):
              * platform/SchemeRegistry.cpp:
              (WebCore::displayIsolatedURLSchemes):
              (WebCore::SchemeRegistry::registerURLSchemeAsLocal):
              (WebCore::SchemeRegistry::removeURLSchemeRegisteredAsLocal):
              (WebCore::SchemeRegistry::localSchemes):
              (WebCore::SchemeRegistry::deprecatedShouldTreatURLAsLocal):
              (WebCore::SchemeRegistry::shouldTreatURLSchemeAsLocal):
              (WebCore::SchemeRegistry::registerURLSchemeAsDisplayIsolated):
              (WebCore::SchemeRegistry::shouldTreatURLSchemeAsDisplayIsolated):
              * platform/SchemeRegistry.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75455 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c655f688
    • tonyg@chromium.org's avatar
      2011-01-09 Tony Gentilcore <tonyg@chromium.org> · b625f859
      tonyg@chromium.org authored
              Reviewed by Alexey Proskuryakov.
      
              Forward declare some headers where possible
              https://bugs.webkit.org/show_bug.cgi?id=52133
      
              No new tests because no new functionality.
      
              * css/CSSValue.h:
              * dom/BeforeLoadEvent.h:
              * dom/Event.cpp:
              * dom/Event.h:
              * dom/StyledElement.cpp:
              * dom/StyledElement.h:
              * loader/DocumentLoader.h:
              * loader/FrameLoader.h:
              * page/Frame.h:
              * platform/graphics/GraphicsContext.cpp:
              * platform/graphics/GraphicsContext.h:
              * platform/graphics/filters/FEBlend.cpp:
              * platform/graphics/filters/FEColorMatrix.cpp:
              * platform/graphics/filters/FEComponentTransfer.cpp:
              * platform/graphics/filters/FEComposite.cpp:
              * platform/graphics/filters/FEConvolveMatrix.cpp:
              * platform/graphics/filters/FEDiffuseLighting.cpp:
              * platform/graphics/filters/FEDisplacementMap.cpp:
              * platform/graphics/filters/FEFlood.cpp:
              * platform/graphics/filters/FEGaussianBlur.cpp:
              * platform/graphics/filters/FEMerge.cpp:
              * platform/graphics/filters/FEMorphology.cpp:
              * platform/graphics/filters/FEOffset.cpp:
              * platform/graphics/filters/FESpecularLighting.cpp:
              * platform/graphics/filters/FETile.cpp:
              * platform/graphics/filters/FETurbulence.cpp:
              * platform/graphics/filters/FilterEffect.cpp:
              * platform/graphics/filters/FilterEffect.h:
              * platform/graphics/filters/SourceAlpha.cpp:
              * platform/graphics/filters/SourceGraphic.cpp:
              * svg/SVGElement.cpp:
              * svg/SVGElement.h:
              * svg/SVGFEBlendElement.cpp:
              * svg/SVGFEColorMatrixElement.cpp:
              * svg/SVGFEComponentTransferElement.cpp:
              * svg/SVGFECompositeElement.cpp:
              * svg/SVGFEConvolveMatrixElement.cpp:
              * svg/SVGFEConvolveMatrixElement.h:
              * svg/SVGFEDiffuseLightingElement.cpp:
              * svg/SVGFEDisplacementMapElement.cpp:
              * svg/SVGFEGaussianBlurElement.cpp:
              * svg/SVGFEImageElement.h:
              * svg/SVGFEMergeElement.cpp:
              * svg/SVGFEMorphologyElement.cpp:
              * svg/SVGFEOffsetElement.cpp:
              * svg/SVGFESpecularLightingElement.cpp:
              * svg/SVGFETileElement.cpp:
              * svg/SVGFETurbulenceElement.h:
              * svg/SVGFilterPrimitiveStandardAttributes.cpp:
              * svg/SVGFilterPrimitiveStandardAttributes.h:
              * svg/SVGTextContentElement.cpp:
              * svg/graphics/filters/SVGFEImage.cpp:
              * svg/graphics/filters/SVGFEImage.h:
      2011-01-09  Tony Gentilcore  <tonyg@chromium.org>
      
              Reviewed by Alexey Proskuryakov.
      
              Forward declare some headers where possible
              https://bugs.webkit.org/show_bug.cgi?id=52133
      
              * WebView/WebFrame.mm:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75377 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      b625f859
  5. 09 Jan, 2011 1 commit
    • commit-queue@webkit.org's avatar
      2011-01-09 Xianzhu Wang <phnixwxz@gmail.com> · 5fcd213d
      commit-queue@webkit.org authored
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation.
              Let client APIs know which URL a new window will start with
      
              * loader/FrameLoader.cpp:
              (WebCore::createWindow):
              * page/ContextMenuController.cpp:
              (WebCore::openNewWindow):
              * page/DOMWindow.cpp:
              (WebCore::DOMWindow::createWindow):
      2011-01-09  Xianzhu Wang  <phnixwxz@gmail.com>
      
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation.
              Pass URL request to createView.
      
              * public/WebViewClient.h:
              (WebKit::WebViewClient::createView):
              * src/ChromeClientImpl.cpp:
              (WebKit::ChromeClientImpl::createWindow):
      2011-01-09  Xianzhu Wang <phnixwxz@gmail.com>
      
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation
      
              * WebCoreSupport/ChromeClientEfl.cpp:
              (WebCore::ChromeClientEfl::createWindow):
      2011-01-09  Xianzhu Wang <phnixwxz@gmail.com>
      
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation
      
              * WebCoreSupport/ChromeClientGtk.cpp:
              (WebKit::ChromeClient::createWindow):
      2011-01-09  Xianzhu Wang <phnixwxz@gmail.com>
      
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation
      
              * WebCoreSupport/WebChromeClient.mm:
              (WebChromeClient::createWindow):
      2011-01-09  Xianzhu Wang <phnixwxz@gmail.com>
      
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation
      
              * Api/qwebpage.cpp:
              (openNewWindow):
              * WebCoreSupport/ChromeClientQt.cpp:
              (WebCore::ChromeClientQt::createWindow):
      2011-01-09  Xianzhu Wang <phnixwxz@gmail.com>
      
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation
      
              * WebCoreSupport/WebChromeClient.cpp:
              (WebChromeClient::createWindow):
      2011-01-09  Xianzhu Wang <phnixwxz@gmail.com>
      
              Reviewed by Darin Fisher.
      
              https://bugs.webkit.org/show_bug.cgi?id=41441
              createWindow method should only do window-creating without URL navigation
      
              * WebKitSupport/ChromeClientWx.cpp:
              (WebCore::ChromeClientWx::createWindow):
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@75349 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5fcd213d
  6. 08 Jan, 2011 1 commit