Add WKVisitedLinkProvider
https://bugs.webkit.org/show_bug.cgi?id=129343

Reviewed by Sam Weinig.

* UIProcess/API/Cocoa/WKVisitedLinkProvider.h: Copied from Source/WebKit2/UIProcess/API/Cocoa/WKWebViewConfiguration.h.
* UIProcess/API/Cocoa/WKVisitedLinkProvider.mm: Copied from Source/WebKit2/UIProcess/API/Cocoa/WKWebViewConfiguration.h.
* UIProcess/API/Cocoa/WKVisitedLinkProviderInternal.h: Copied from Source/WebKit2/UIProcess/API/Cocoa/WKWebViewConfiguration.h.
* UIProcess/API/Cocoa/WKVisitedLinkProviderPrivate.h: Copied from Source/WebKit2/UIProcess/API/Cocoa/WKWebViewConfiguration.h.
* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView initWithFrame:configuration:]):
* UIProcess/API/Cocoa/WKWebViewConfiguration.h:
* UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
(-[WKWebViewConfiguration visitedLinkProvider]):
(-[WKWebViewConfiguration setVisitedLinkProvider:]):
* WebKit2.xcodeproj/project.pbxproj:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164681 268f45cc-cd09-0410-ab3c-d52691b4dbfc
DrawingAreaProxy is using WebCore's Timer
https://bugs.webkit.org/show_bug.cgi?id=129347
<rdar://problem/16078133>

Reviewed by Tim Horton.

Use a RunLoop::Timer instead.

* UIProcess/DrawingAreaProxy.cpp:
(WebKit::DrawingAreaProxy::DrawingAreaProxy):
(WebKit::DrawingAreaProxy::exposedRectChangedTimerFired):
* UIProcess/DrawingAreaProxy.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164682 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Need to initialize VM stack data even when the VM is on an exclusive thread.
<https://webkit.org/b/129265>

Not reviewed.

Source/JavaScriptCore: 

Relanding r164627 now that <https://webkit.org/b/129341> is fixed.

* API/APIShims.h:
(JSC::APIEntryShim::APIEntryShim):
(JSC::APICallbackShim::shouldDropAllLocks):
* heap/MachineStackMarker.cpp:
(JSC::MachineThreads::addCurrentThread):
* runtime/JSLock.cpp:
(JSC::JSLockHolder::JSLockHolder):
(JSC::JSLockHolder::init):
(JSC::JSLockHolder::~JSLockHolder):
(JSC::JSLock::JSLock):
(JSC::JSLock::setExclusiveThread):
(JSC::JSLock::lock):
(JSC::JSLock::unlock):
(JSC::JSLock::currentThreadIsHoldingLock):
(JSC::JSLock::dropAllLocks):
(JSC::JSLock::grabAllLocks):
* runtime/JSLock.h:
(JSC::JSLock::hasExclusiveThread):
(JSC::JSLock::exclusiveThread):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::hasExclusiveThread):
(JSC::VM::exclusiveThread):
(JSC::VM::setExclusiveThread):
(JSC::VM::currentThreadIsHoldingAPILock):

Source/WebCore: 

No new tests.

Relanding r164627 now that <https://webkit.org/b/129341> is fixed.

* bindings/js/JSDOMBinding.cpp:
(WebCore::reportException):
* bindings/js/JSDOMWindowBase.cpp:
(WebCore::JSDOMWindowBase::commonVM):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164683 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make WebContext handle populating visited links
https://bugs.webkit.org/show_bug.cgi?id=129348

Reviewed by Tim Horton.

This makes it possible to decouple VisitedLinkProvider from WebContext.

* UIProcess/VisitedLinkProvider.cpp:
(WebKit::VisitedLinkProvider::VisitedLinkProvider):
(WebKit::VisitedLinkProvider::processDidFinishLaunching):
* UIProcess/VisitedLinkProvider.h:
* UIProcess/WebContext.cpp:
(WebKit::WebContext::WebContext):
(WebKit::WebContext::processDidFinishLaunching):
* UIProcess/WebContext.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164684 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add accessibility search predicate support for AXOutlines
https://bugs.webkit.org/show_bug.cgi?id=123748

Reviewed by Chris Fleizach.

Source/WebCore:

Added new AXOutlineSearchKey to support finding elements with aria role=tree.

No new tests, updated existing search-predicate.html test to cover AXOutlineSearchKey.

* accessibility/AccessibilityObject.cpp:
(WebCore::AccessibilityObject::isAccessibilityObjectSearchMatchAtIndex):
* accessibility/AccessibilityObject.h:
* accessibility/mac/WebAccessibilityObjectWrapperMac.mm:
(createAccessibilitySearchKeyMap):

LayoutTests:

Updated test to validate support for AXOutlineSearchKey (elements with aria role=tree).

* platform/mac/accessibility/search-predicate-expected.txt:
* platform/mac/accessibility/search-predicate.html:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164685 268f45cc-cd09-0410-ab3c-d52691b4dbfc
VisitedLinkProvider should be refcounted
https://bugs.webkit.org/show_bug.cgi?id=129351

Reviewed by Sam Weinig.

* UIProcess/VisitedLinkProvider.cpp:
(WebKit::VisitedLinkProvider::create):
(WebKit::VisitedLinkProvider::~VisitedLinkProvider):
* UIProcess/VisitedLinkProvider.h:
* UIProcess/WebContext.cpp:
(WebKit::WebContext::WebContext):
(WebKit::WebContext::processDidFinishLaunching):
(WebKit::WebContext::disconnectProcess):
(WebKit::WebContext::addVisitedLinkHash):
* UIProcess/WebContext.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164686 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: CRASH when evaluating in console of JSContext RWI with disabled breakpoints.
<https://webkit.org/b/128766>

Reviewed by Geoffrey Garen.

Make the JSLock::grabAllLocks() work the same way as for the C loop LLINT.
The reasoning is that we don't know of any clients that need unordered
re-entry into the VM from different threads. So, we're enforcing ordered
re-entry i.e. we must re-grab locks in the reverse order of dropping locks.

The crash in this bug happened because we were allowing unordered re-entry,
and the following type of scenario occurred:

1. Thread T1 locks the VM, and enters the VM to execute some JS code.
2. On entry, T1 detects that VM::m_entryScope is null i.e. this is the
   first time it entered the VM.
   T1 sets VM::m_entryScope to T1's entryScope.
3. T1 drops all locks.

4. Thread T2 locks the VM, and enters the VM to execute some JS code.
   On entry, T2 sees that VM::m_entryScope is NOT null, and therefore
   does not set the entryScope.
5. T2 drops all locks.

6. T1 re-grabs locks.
7. T1 returns all the way out of JS code. On exit from the outer most
   JS function, T1 clears VM::m_entryScope (because T1 was the one who
   set it).
8. T1 unlocks the VM.

9. T2 re-grabs locks.
10. T2 proceeds to execute some code and expects VM::m_entryScope to be
    NOT null, but it turns out to be null. Assertion failures and
    crashes ensue.

With ordered re-entry, at step 6, T1 will loop and yield until T2 exits
the VM. Hence, the issue will no longer manifest.

* runtime/JSLock.cpp:
(JSC::JSLock::dropAllLocks):
(JSC::JSLock::grabAllLocks):
* runtime/JSLock.h:
(JSC::JSLock::DropAllLocks::dropDepth):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164687 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: Port some profiler tests to inspector-protocol
https://bugs.webkit.org/show_bug.cgi?id=129353

Patch by Joseph Pecoraro <pecoraro@apple.com> on 2014-02-25
Reviewed by Timothy Hatcher.

* inspector-obsolete/profiler/cpu-profiler-parameterless-profile-end-crash-expected.txt: Removed.
* inspector-obsolete/profiler/cpu-profiler-parameterless-profile-end-crash.html: Removed.
* inspector-obsolete/profiler/cpu-profiler-profiling-without-inspector-expected.txt: Removed.
* inspector-obsolete/profiler/cpu-profiler-profiling-without-inspector.html: Removed.
* inspector-protocol/profiler/console-profile-expected.txt: Added.
* inspector-protocol/profiler/console-profile.html: Added.
* inspector-protocol/profiler/console-profileEnd-parameterless-expected.txt: Added.
* inspector-protocol/profiler/console-profileEnd-parameterless.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164689 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WebKit2] Form controls handling.
https://bugs.webkit.org/show_bug.cgi?id=129344
<rdar://problem/16053643>

Reviewed by Simon Fraser and Joseph Pecoraro.

../WebCore: 

Adding some exports.
        
* WebCore.exp.in:

../WebKit2: 

This is the step toward adding support for
form controls iOS style. It adds the logic to
select the appropriate keyboard type based on the
element type and introduces the AssistedNodeInformation
structure used currently for the keyboard type selection
and that will be used to populate pickers and popovers.
It also provides information to enable/disable next/previous
buttons in the accessory view.

* Scripts/webkit2/messages.py:
(struct_or_class):
* Shared/AssistedNodeInformation.cpp: Added.
(WebKit::AssistedNodeInformation::encode):
(WebKit::AssistedNodeInformation::decode):
* Shared/AssistedNodeInformation.h: Added.
(WebKit::AssistedNodeInformation::AssistedNodeInformation):
* UIProcess/PageClient.h:
* UIProcess/WebPageProxy.h:
* UIProcess/WebPageProxy.messages.in:
* UIProcess/ios/PageClientImplIOS.h:
* UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::startAssistingNode):
* UIProcess/ios/WKContentViewInteraction.h:
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView _requiresKeyboardWhenFirstResponder]):
(-[WKContentView _updateAccessory]):
(toUITextAutocapitalize):
(-[WKContentView textInputTraits]):
(-[WKContentView assistedNodeInformation]):
(-[WKContentView _startAssistingNode:]):
(-[WKContentView _stopAssistingNode]):
* UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::startAssistingNode):
* WebKit2.xcodeproj/project.pbxproj:
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::isAssistableNode):
(WebKit::hasFocusableNode):
(WebKit::WebPage::getAssistedNodeInformation):
(WebKit::WebPage::elementDidFocus):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164690 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Rename WebCore::VisitedLinkProvider to WebCore::VisitedLinkStore
https://bugs.webkit.org/show_bug.cgi?id=129357

Reviewed by Sam Weinig.

Source/WebCore:

* WebCore.exp.in:
* WebCore.xcodeproj/project.pbxproj:
* dom/VisitedLinkState.cpp:
(WebCore::VisitedLinkState::determineLinkStateSlowCase):
* loader/HistoryController.cpp:
(WebCore::addVisitedLink):
* page/DefaultVisitedLinkStore.cpp: Renamed from Source/WebCore/page/DefaultVisitedLinkProvider.cpp.
(WebCore::DefaultVisitedLinkStore::create):
(WebCore::DefaultVisitedLinkStore::DefaultVisitedLinkStore):
(WebCore::DefaultVisitedLinkStore::~DefaultVisitedLinkStore):
(WebCore::DefaultVisitedLinkStore::isLinkVisited):
(WebCore::DefaultVisitedLinkStore::addVisitedLink):
* page/DefaultVisitedLinkStore.h: Renamed from Source/WebCore/page/DefaultVisitedLinkProvider.h.
* page/Page.cpp:
(WebCore::Page::Page):
(WebCore::Page::visitedLinkStore):
* page/Page.h:
* page/PageGroup.cpp:
(WebCore::PageGroup::visitedLinkStore):
* page/PageGroup.h:
* page/VisitedLinkStore.cpp: Renamed from Source/WebCore/page/VisitedLinkProvider.cpp.
(WebCore::VisitedLinkStore::VisitedLinkStore):
(WebCore::VisitedLinkStore::~VisitedLinkStore):
* page/VisitedLinkStore.h: Renamed from Source/WebCore/page/VisitedLinkProvider.h.

Source/WebKit2:

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::WebPage):
* WebProcess/WebPage/WebVisitedLinkProvider.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164691 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Build fix for OS X after r164690

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-02-25

* WebCore.exp.in:


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

* CMakeLists.txt:
* GNUmakefile.list.am:
* WebCore.vcxproj/WebCore.vcxproj:
* WebCore.vcxproj/WebCore.vcxproj.filters:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164696 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Subpixel layout: Remove explicit static_cast<LayoutUnit> conversions.
https://bugs.webkit.org/show_bug.cgi?id=129359

Reviewed by Simon Fraser.

No testable change in behavior.

* css/LengthFunctions.cpp:
(WebCore::minimumValueForLength):
* page/FrameView.cpp:
(WebCore::FrameView::forceLayoutForPagination):
* rendering/InlineFlowBox.cpp:
(WebCore::InlineFlowBox::paintFillLayer):
* rendering/InlineFlowBox.h:
(WebCore::InlineFlowBox::logicalLeftVisualOverflow):
(WebCore::InlineFlowBox::logicalRightVisualOverflow):
* rendering/InlineTextBox.cpp:
(WebCore::InlineTextBox::isSelected):
* rendering/RenderBlock.cpp:
(WebCore::RenderBlock::computeColumnCountAndWidth):
(WebCore::getBPMWidth):
* rendering/RenderBlockFlow.cpp:
(WebCore::RenderBlockFlow::adjustForBorderFit):
* rendering/RenderDeprecatedFlexibleBox.cpp:
(WebCore::RenderDeprecatedFlexibleBox::layoutVerticalBox):
* rendering/RenderFieldset.cpp:
(WebCore::RenderFieldset::paintBoxDecorations):
* rendering/RenderTable.h:
(WebCore::RenderTable::borderSpacingInRowDirection):
* rendering/RenderTextControlMultiLine.cpp:
(WebCore::RenderTextControlMultiLine::preferredContentLogicalWidth):
* rendering/RenderTextControlSingleLine.cpp:
(WebCore::RenderTextControlSingleLine::preferredContentLogicalWidth):
* rendering/RootInlineBox.cpp:
(WebCore::RootInlineBox::beforeAnnotationsAdjustment):
(WebCore::RootInlineBox::ascentAndDescentForBox):
* rendering/svg/RenderSVGRoot.cpp:
(WebCore::resolveLengthAttributeForSVG):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164697 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Subpixel rendering: Ensure consistent border painting width.
https://bugs.webkit.org/show_bug.cgi?id=129259

Reviewed by Simon Fraser.

Border edges are painted as (semi)independent rectangles. When snapping an edge rectangle
to device pixels, its painted dimensions depend on its size and its fractional position.
Specific combination of position and border width can result in painting edges sized differently.
Using device snapped border width to calculate inner/outer rectangles helps to maintain
uniform border width.

Currently not testable.

* rendering/RenderBoxModelObject.cpp:
(WebCore::BorderEdge::BorderEdge):
(WebCore::BorderEdge::shouldRender):
(WebCore::BorderEdge::presentButInvisible):
(WebCore::BorderEdge::widthForPainting):
(WebCore::BorderEdge::getDoubleBorderStripeWidths):
(WebCore::RenderBoxModelObject::paintOneBorderSide):
(WebCore::calculateSideRect):
(WebCore::RenderBoxModelObject::paintBorderSides):
(WebCore::RenderBoxModelObject::paintBorder):
(WebCore::RenderBoxModelObject::drawBoxSideFromPath):
(WebCore::calculateSideRectIncludingInner):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164698 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSSRegions] Small clean-up of flow threads accelerated compositing code
https://bugs.webkit.org/show_bug.cgi?id=129312

Reviewed by Andrei Bucur.

Some clean-up for the code used for regions in accelerated compositing functionality:
1. Rename updateRenderFlowThreadLayersIfNeeded -> updateFlowThreadsLayerToRegionMappingsIfNeeded
as the function updates the mapping between the flow threads layers and their corresponding regions
2. Remove RenderLayerCompositor::updateRenderFlowThreadLayersIfNeeded and move the code in place
at call site since the function body does not require a dedicated function.

No new functionality, no new tests.

* rendering/FlowThreadController.cpp:
(WebCore::FlowThreadController::updateFlowThreadsLayerToRegionMappingsIfNeeded):
Now that the regions are always layers, we do not need to iterate backwards.
* rendering/FlowThreadController.h:
* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::updateCompositingLayers):
* rendering/RenderLayerCompositor.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164699 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add support for minsize/maxsize attributes.
https://bugs.webkit.org/show_bug.cgi?id=122567

Reviewed by Chris Fleizach.

Source/WebCore:

This change implements the minsize/maxsize attributes of the mo element.
We also switch stretch sizes from int to LayoutUnit to improve accuracy.

Tests: mathml/presentation/stretchy-minsize-maxsize-dynamic.html
       mathml/presentation/stretchy-minsize-maxsize.html

* rendering/mathml/RenderMathMLOperator.cpp:
(WebCore::RenderMathMLOperator::SetOperatorProperties):
(WebCore::RenderMathMLOperator::stretchTo):
* rendering/mathml/RenderMathMLOperator.h:
* rendering/mathml/RenderMathMLRow.cpp:
(WebCore::RenderMathMLRow::layout):

LayoutTests:

Add some reftests for the minsize/maxsize attributes of the mo element.

* platform/mac/mathml/presentation/mo-stretch-expected.txt:
* mathml/presentation/stretchy-minsize-maxsize-dynamic-expected.html: Added.
* mathml/presentation/stretchy-minsize-maxsize-dynamic.html: Added.
* mathml/presentation/stretchy-minsize-maxsize-expected.html: Added.
* mathml/presentation/stretchy-minsize-maxsize.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164700 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Add myself as a committer.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164701 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS][WK2] Split the rects/scale updates in 3 internally consistent groups
https://bugs.webkit.org/show_bug.cgi?id=129354

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-02-25
Reviewed by Sam Weinig.

During scaling, the scale and rect of UIScrollView, WebPageProxy, DrawingAreaProxy,
DrawingArea and WebPage were in completely inconsistent states.

Some of those disconnect were temporary (like when setting the rect and scale in two different
messages), some were lasting the time of a tile update (like the UIProcess view of the scale).
This was causing various visual glitches.

To fix this, all the updates from the UIProcess are funneled through a single path and the values
are split into 3 different groups/types.
When updating the scale/rects, the UIProcess sends the new information to the WebProcess on a queue
through ViewUpdateDispatcher. There, the updates are accumulated until the MainThread is available.
Once the main thread is "unblocked" from the previous frame, all the data are updated at once from
the last known state in ViewUpdateDispatcher. The new tiles are created for the new converage information
and they are sent to the UIProcess.

At any point, there are 3 types of scale and rects used for different purpose:
-In the UIProcess, there is the UIScrollView scale and rects which represent the "true" state or what
 is currently on screen.
 That information is mirrored into WebPageProxy for the other classes needing it like DrawingAreaProxy.
-In the WebProcess, there is the last known state. That state is always lagging a little behind the "true"
 state.
-Back in the UIProcess, we have the tile states that is attached to RemoteLayerTreeTransaction. It is used
 to setup the rendering.

With this change, there are two paths for updating the page scale factor:
-The UI drives the change, the updates goes WKWebView->WKContentView->WebPageProxy->ViewUpdateDispatcher
 ->WebPage->RemoteLayerTreeDrawingArea->RemoteLayerTreeDrawingAreaProxy->WKContentView->WKWebView.
-If changes in the content force scaling parameters, the updates goes: WebPage->RemoteLayerTreeDrawingArea
 ->RemoteLayerTreeDrawingAreaProxy->WKContentView->WKWebView.
The two kind of updates frequently conflicts during loading. We differentiate those through the flag
scaleWasSetByUIProcess passed with the updates. In cases of conflicts, the user always wins.

* DerivedSources.make:
* Scripts/webkit2/messages.py:
(struct_or_class):
* Shared/VisibleContentRectUpdateInfo.cpp: Added.
(WebKit::VisibleContentRectUpdateInfo::encode):
(WebKit::VisibleContentRectUpdateInfo::decode):
* Shared/VisibleContentRectUpdateInfo.h: Added.
(WebKit::VisibleContentRectUpdateInfo::VisibleContentRectUpdateInfo):
(WebKit::VisibleContentRectUpdateInfo::exposedRect):
(WebKit::VisibleContentRectUpdateInfo::unobscuredRect):
(WebKit::VisibleContentRectUpdateInfo::scale):
(WebKit::operator==):
* Shared/mac/RemoteLayerTreeTransaction.h:
(WebKit::RemoteLayerTreeTransaction::scaleWasSetByUIProcess):
(WebKit::RemoteLayerTreeTransaction::setScaleWasSetByUIProcess):
* Shared/mac/RemoteLayerTreeTransaction.mm:
(WebKit::RemoteLayerTreeTransaction::encode):
(WebKit::RemoteLayerTreeTransaction::decode):
* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView contentView:didCommitLayerTree:WebKit::]):
(-[WKWebView _didFinishScrolling]):
(-[WKWebView scrollViewDidScroll:]):
(-[WKWebView scrollViewDidZoom:]):
(-[WKWebView scrollViewDidEndZooming:withView:atScale:]):
(-[WKWebView _frameOrBoundsChanged]):
(-[WKWebView _updateVisibleContentRectsWithStableState:]):
(-[WKWebView _setObscuredInsets:]):
(-[WKWebView _endInteractiveObscuredInsetsChange]):
* UIProcess/API/ios/WKViewIOS.mm:
(-[WKView _updateVisibleContentRects]):
* UIProcess/DrawingAreaProxy.cpp:
(WebKit::DrawingAreaProxy::DrawingAreaProxy):
(WebKit::DrawingAreaProxy::setCustomFixedPositionRect):
* UIProcess/DrawingAreaProxy.h:
(WebKit::DrawingAreaProxy::updateDebugIndicator):
* UIProcess/WebPageProxy.h:
(WebKit::WebPageProxy::displayedContentScale):
(WebKit::WebPageProxy::exposedContentRect):
(WebKit::WebPageProxy::unobscuredContentRect):
* UIProcess/ios/WKContentView.h:
* UIProcess/ios/WKContentView.mm:
(-[WKContentView didUpdateVisibleRect:unobscuredRect:scale:inStableState:]):
(-[WKContentView didFinishScrolling]):
(-[WKContentView didZoomToScale:]):
* UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::updateVisibleContentRects):
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.h:
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::scaledExposedRect):
(WebKit::RemoteLayerTreeDrawingAreaProxy::indicatorLocation):
(WebKit::RemoteLayerTreeDrawingAreaProxy::indicatorScale):
(WebKit::RemoteLayerTreeDrawingAreaProxy::updateDebugIndicator):
* WebKit2.xcodeproj/project.pbxproj:
* WebProcess/WebPage/ViewUpdateDispatcher.cpp: Added.
(WebKit::ViewUpdateDispatcher::create):
(WebKit::ViewUpdateDispatcher::ViewUpdateDispatcher):
(WebKit::ViewUpdateDispatcher::~ViewUpdateDispatcher):
(WebKit::ViewUpdateDispatcher::initializeConnection):
(WebKit::ViewUpdateDispatcher::visibleContentRectUpdate):
(WebKit::ViewUpdateDispatcher::dispatchVisibleContentRectUpdate):
* WebProcess/WebPage/ViewUpdateDispatcher.h: Added.
* WebProcess/WebPage/ViewUpdateDispatcher.messages.in: Added.
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::WebPage):
(WebKit::WebPage::scalePage):
* WebProcess/WebPage/WebPage.h:
(WebKit::WebPage::scaleWasSetByUIProcess):
* WebProcess/WebPage/WebPage.messages.in:
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::tapHighlightAtPosition):
(WebKit::WebPage::updateVisibleContentRects):
(WebKit::WebPage::willStartUserTriggeredZooming):
* WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::flushLayers):
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::WebProcess):
(WebKit::WebProcess::initializeConnection):
* WebProcess/WebProcess.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164702 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] generate-gtkdoc can fail with WebKit1 or WebKit2 only builds
https://bugs.webkit.org/show_bug.cgi?id=129319

Patch by Martin Robinson <mrobinson@igalia.com> on 2014-02-26
Reviewed by Carlos Garcia Campos.

Source/WebKit/gtk:

* GNUmakefile.am: Do not generate the documentation configuration file if the port
is disabled.

Source/WebKit2:

* GNUmakefile.am: Do not generate the documentation configuration file if the port
is disabled.

Tools:

* gtk/generate-gtkdoc:
(get_generator_for_config): Properly handle the situation where the pkgconfig file is missing.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@164704 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Avoid unnecessary HTML Collection invalidations for id and name attribute changes
https://bugs.webkit.org/show_bug.cgi?id=129361

Reviewed by Benjamin Poulain.

Before this patch, setting id and name attributes resulted in traversing all the ancestors to invalidate
HTML collections on those nodes whenever we had more than one HTMLCollection alive.

Avoid the traversal when HTMLCollections don't have any valid id and name map caches by making each
HTMLCollection explicitly call collectionCachedIdNameMap and collectionWillClearIdNameMap when it caches
or clears the id and name map.

Inspired by https://chromium.googlesource.com/chromium/blink/+/5b06b91b79098f7d42e480f85be32198315d2440

* dom/Document.cpp:
(WebCore::Document::registerCollection): Takes a boolean to indicate whether collection has a valid cache
for the id and name map.
(WebCore::Document::unregisterCollection): Ditto.
(WebCore::Document::collectionCachedIdNameMap): Added.
(WebCore::Document::collectionWillClearIdNameMap): Added.
* dom/Document.h:

* dom/NodeRareData.h:
(WebCore::NodeListsNodeData::adoptDocument): Call invalidateCache on HTML collections after, not before,
calling unregisterCollection and registerCollection since collections' owner nodes have already been
moved to the new document here and invalidateCache uses owner node's document to call
collectionWillClearIdNameMap. So calling invalidateCache before calling unregister/registerCollection
would result in collectionWillClearIdNameMap getting called on a wrong document.

* html/HTMLCollection.cpp:
(WebCore::HTMLCollection::HTMLCollection):
(WebCore::HTMLCollection::~HTMLCollection):
(WebCore::HTMLCollection::invalidateCache):
(WebCore::HTMLCollection::invalidateIdNameCacheMaps): Added the code to uncount itself from the number
of live node lists and HTML collections that need to be invalidated upon id and name attribute changes.
(WebCore::HTMLCollection::updateNameCache):

* html/HTMLCollection.h:
(WebCore::HTMLCollection::invalidateCache):
(WebCore::HTMLCollection::hasIdNameCache): Renamed from hasNameCache.
(WebCore::HTMLCollection::setHasIdNameCache): Renamed from setHasIdNameCache.

* html/HTMLFormControlsCollection.cpp:
(WebCore::HTMLFormControlsCollection::updateNameCache):


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