Rename functions in SVGDocumentExtension
https://bugs.webkit.org/show_bug.cgi?id=127046

Reviewed by Sam Weinig.

Change some function names in SVGDocumentExtension
to make them more descriptive.

Simple refactoring. No new tests.

* rendering/svg/RenderSVGResourceContainer.cpp:
(WebCore::RenderSVGResourceContainer::registerResource):
* svg/SVGDocumentExtensions.cpp:
(WebCore::SVGDocumentExtensions::addPendingResource):
(WebCore::SVGDocumentExtensions::isIdOfPendingResource):
(WebCore::SVGDocumentExtensions::isElementWithPendingResources):
(WebCore::SVGDocumentExtensions::isPendingResource):
(WebCore::SVGDocumentExtensions::clearHasPendingResourcesIfPossible):
(WebCore::SVGDocumentExtensions::removeElementFromPendingResources):
(WebCore::SVGDocumentExtensions::removePendingResource):
(WebCore::SVGDocumentExtensions::removePendingResourceForRemoval):
(WebCore::SVGDocumentExtensions::markPendingResourcesForRemoval):
(WebCore::SVGDocumentExtensions::removeElementFromPendingResourcesForRemovalMap): The name is not great but a bit more descriptive.
* svg/SVGDocumentExtensions.h:
* svg/SVGElement.cpp:
(WebCore::SVGElement::buildPendingResourcesIfNeeded):
* svg/SVGMPathElement.cpp:
(WebCore::SVGMPathElement::buildPendingResource):
* svg/SVGTextPathElement.cpp:
(WebCore::SVGTextPathElement::buildPendingResource):
* svg/animation/SVGSMILElement.cpp:
(WebCore::SVGSMILElement::buildPendingResource):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@162119 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] Fix build issues with exported headers

Source/WebCore:

* Configurations/WebCore.xcconfig: Allowed UIKit to link against
WebCore.
* page/ios/WebEventRegion.h: Removed ENABLE(TOUCH_EVENTS), which are
always enabled on iOS.

Source/WebKit:

* WebKit.xcodeproj/project.pbxproj: Removed WebPluginPrivate.h from
the project.

Source/WebKit/ios:

* Misc/WebNSStringExtrasIOS.h: Changed PLATFORM(IOS) to
TARGET_OS_IPHONE.

Source/WebKit/mac:

* DOM/WebDOMOperationsPrivate.h: Changed PLATFORM(IOS) to
TARGET_OS_IPHONE.
* MigrateHeaders.make: Excluded WAKScrollView.h from normal replacement
rules so that WebCoreFrameScrollView won't inadvertently get changed to
WebKitFrameScrollView.
* Plugins/WebPlugin.h: Moved contents of WebPluginPrivate.h to here in
order to maintain source compatibility.
* Plugins/WebPluginController.mm: Removed an import of WebPluginPrivate.h.
* Plugins/WebPluginPrivate.h: Removed.
* Storage/WebDatabaseManagerPrivate.h: Replaced ENABLE(SQL_DATABASE)
with ENABLE_SQL_DATABASE.
* WebView/WebViewPrivate.h: Added declaration of
-[WebView _touchEventRegions] for source compatibility.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@162120 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Expose scrollView on WKView
https://bugs.webkit.org/show_bug.cgi?id=127085

Patch by Ian Henderson <ianh@apple.com> on 2014-01-16
Reviewed by Antti Koivisto.

Expose WKView's scroll view as a property.  In order to support
clients calling setDelegate:, we create a forwarder object that sends
delegate methods to both WKView (the "internal delegate") and the
publicly-exposed delegate (the "external delegate").

* UIProcess/API/Cocoa/WKView.h:
* UIProcess/API/ios/WKScrollView.h:
* UIProcess/API/ios/WKScrollView.mm:
(-[WKScrollViewDelegateForwarder initWithInternalDelegate:externalDelegate:]):
(-[WKScrollViewDelegateForwarder methodSignatureForSelector:]):
(-[WKScrollViewDelegateForwarder respondsToSelector:]):
(-[WKScrollViewDelegateForwarder forwardInvocation:]):
(-[WKScrollView setInternalDelegate:]):
(-[WKScrollView setDelegate:]):
(-[WKScrollView delegate]):
Pretend like _externalDelegate is the real delegate to avoid exposing
our internal delegate or forwarder object.
(-[WKScrollView _updateDelegate]):
(-[WKScrollView dealloc]):
* UIProcess/API/ios/WKViewIOS.mm:
(-[WKView scrollView]):
(-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@162121 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK][MiniBrowser] The progress entry reset callback can be fired after the BrowserWindow is destroyed
https://bugs.webkit.org/show_bug.cgi?id=127083

Reviewed by Carlos Garcia Campos.

When the load progress reaches 1.0 (i.e. 100%), a timeout callback is set up in webViewLoadProgressChanged.
The progress entry is then reset back to 0 in that callback and the timeout source is removed.

The callback can be fired after the relevant BrowserWindow and its progress entry are destroyed, causing
assertion failures in gtk_entry_set_progress_fraction due to an invalid GtkEntry object. To avoid that,
To avoid that, the ID of the timeout source is stored on the BrowserWindow and is destroyed when the
BrowserWindow object is being finalized, preventing the callback from firing.

* MiniBrowser/gtk/BrowserWindow.c:
(resetEntryProgress):
(webViewLoadProgressChanged):
(browserWindowFinalize):


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