Add HTMLNames::classAttr has a regular name in SVGElement::isAnimatableAttribute
https://bugs.webkit.org/show_bug.cgi?id=128166

Reviewed by Sam Weinig.

For historical reasons, classAttr was treated separately. There is no reasons for that anymore.

* svg/SVGElement.cpp:
(WebCore::SVGElement::isAnimatableAttribute):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163510 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add HTMLNames::classAttr as a regular name in SVGElement::isAnimatableAttribute
https://bugs.webkit.org/show_bug.cgi?id=128166

Reviewed by Sam Weinig.

For historical reasons, classAttr was treated separately. There is no reasons for that anymore.

* svg/SVGElement.cpp:
(WebCore::SVGElement::isAnimatableAttribute):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163511 268f45cc-cd09-0410-ab3c-d52691b4dbfc
SelectorCodeGenerator::generateElementHasTagName should match the local name before the namespace
https://bugs.webkit.org/show_bug.cgi?id=128167

Reviewed by Sam Weinig.

The local name is a stricter filter than the namespace, it should always run first.

* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementHasTagName):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163512 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't speculate on ToThis if we already know that arg0 has a questionable record with structure checks
https://bugs.webkit.org/show_bug.cgi?id=128229

Reviewed by Geoffrey Garen.

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163513 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Add the minimumLayoutSizeOverride SPI to WKWebView
https://bugs.webkit.org/show_bug.cgi?id=128295

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-02-05
Reviewed by Anders Carlsson.

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView minimumLayoutSizeOverride]):
(-[WKWebView setMinimumLayoutSizeOverride:]):
* UIProcess/API/Cocoa/WKWebViewPrivate.h: Added.
* WebKit2.xcodeproj/project.pbxproj:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163514 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] Synchronize the WKContentView and UIScrollView updates with the tiles being commited
https://bugs.webkit.org/show_bug.cgi?id=127886

Reviewed by Simon Fraser.

Source/WebCore: 

The updates of the views on the UIProcess side was completely disconnected
from the tiles updates from the DrawingArea. There is a non-negligible time
between the size/scale update and the new tiles coming, which causes
visual glitches.

There are three main cases where the tiles and content would be out of sync
with the UIViews:
-When loading a new page with different content width of a different viewport.
-When a page changes its viewport.
-When the viewport-constrainted viewport size changes.

To fix the issue, WKView is modified to maintain the old state of WKContentView
and UIScrollView until the new tiles are available.

Geometry/scale update are split in two phases:
1) A source (the page or the user) changes parameters of the geometry. The WebProcess updates
   its layout accordingly.
   At this point, the UIViews are unchanged and are left with the old parameters.
2) Eventually, new tiles come and commitLayerTree() is called on the drawing area proxy.
   At that point, WKContentView and its UIScrollView are updated to match the committed
   size and scale for the page.

* WebCore.exp.in:
* WebCore.xcodeproj/project.pbxproj:
* page/ViewportConfiguration.cpp: Added.
(WebCore::constraintsAreAllRelative):
(WebCore::ViewportConfiguration::ViewportConfiguration):
(WebCore::ViewportConfiguration::setDefaultConfiguration):
(WebCore::ViewportConfiguration::setContentsSize):
(WebCore::ViewportConfiguration::setMinimumLayoutSize):
(WebCore::ViewportConfiguration::setViewportArguments):
(WebCore::ViewportConfiguration::layoutSize):
(WebCore::ViewportConfiguration::initialScale):
(WebCore::ViewportConfiguration::minimumScale):
(WebCore::ViewportConfiguration::maximumScale):
(WebCore::ViewportConfiguration::allowsUserScaling):
(WebCore::viewportArgumentValueIsValid):
(WebCore::applyViewportArgument):
(WebCore::ViewportConfiguration::updateConfiguration):
(WebCore::ViewportConfiguration::layoutWidth):
(WebCore::ViewportConfiguration::layoutHeight):
* page/ViewportConfiguration.h: Added.
(WebCore::ViewportConfigurationConfiguration::ViewportConfigurationConfiguration):
(WebCore::ViewportConfiguration::defaultConfiguration):
(WebCore::ViewportConfiguration::contentsSize):
(WebCore::ViewportConfiguration::minimumLayoutSize):
(WebCore::ViewportConfiguration::viewportArguments):

Source/WebKit2: 

* Shared/mac/RemoteLayerTreeTransaction.h:
(WebKit::RemoteLayerTreeTransaction::mainFrameContentsSize):
(WebKit::RemoteLayerTreeTransaction::setMainFrameContentsSize):
(WebKit::RemoteLayerTreeTransaction::pageScaleFactor):
(WebKit::RemoteLayerTreeTransaction::setPageScaleFactor):
(WebKit::RemoteLayerTreeTransaction::minimumScaleFactor):
(WebKit::RemoteLayerTreeTransaction::setMinimumScaleFactor):
(WebKit::RemoteLayerTreeTransaction::maximumScaleFactor):
(WebKit::RemoteLayerTreeTransaction::setMaximumScaleFactor):
(WebKit::RemoteLayerTreeTransaction::allowsUserScaling):
(WebKit::RemoteLayerTreeTransaction::setAllowsUserScaling):
* Shared/mac/RemoteLayerTreeTransaction.mm:
(WebKit::RemoteLayerTreeTransaction::encode):
(WebKit::RemoteLayerTreeTransaction::decode):
* UIProcess/API/ios/PageClientImplIOS.h:
* UIProcess/API/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::didCommitLayerTree):
* UIProcess/API/ios/WKContentView.h:
* UIProcess/API/ios/WKContentView.mm:
(-[WKContentView setMinimumLayoutSize:]):
(-[WKContentView willStartUserTriggeredZoom]):
(-[WKContentView _didCommitLayerTree:WebKit::]):
* UIProcess/API/ios/WKContentViewInternal.h:
* UIProcess/API/ios/WKViewIOS.mm:
(-[WKView contentViewDidCommitLoadForMainFrame:]):
(-[WKView contentView:didCommitLayerTree:WebKit::]):
(-[WKView scrollViewWillBeginZooming:withView:]):
(-[WKView _commonInitializationWithContextRef:pageGroupRef:relatedToPage:]):
(-[WKView _frameOrBoundsChanged]):
(-[WKView minimumLayoutSizeOverride]):
(-[WKView setMinimumLayoutSizeOverride:]):
* UIProcess/PageClient.h:
* UIProcess/WebPageProxy.cpp:
* UIProcess/WebPageProxy.h:
* UIProcess/WebPageProxy.messages.in:
* UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::setVirtualViewportMinimumLayoutSize):
(WebKit::WebPageProxy::didCommitLayerTree):
(WebKit::WebPageProxy::willStartUserTriggeredZooming):
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
* WebProcess/WebCoreSupport/WebChromeClient.cpp:
(WebKit::WebChromeClient::contentsSizeChanged):
(WebKit::WebChromeClient::dispatchViewportPropertiesDidChange):
* WebProcess/WebCoreSupport/ios/WebChromeClientIOS.mm:
(WebKit::WebChromeClient::didReceiveMobileDocType):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::WebPage):
(WebKit::WebPage::mainFrameDidLayout):
(WebKit::WebPage::didCommitLoad):
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in:
* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::viewportPropertiesDidChange):
(WebKit::WebPage::minimumPageScaleFactor):
(WebKit::WebPage::maximumPageScaleFactor):
(WebKit::WebPage::allowsUserScaling):
(WebKit::WebPage::setVirtualViewportMinimumLayoutSize):
(WebKit::WebPage::virtualViewportChanged):
(WebKit::WebPage::willStartUserTriggeredZooming):
* WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::flushLayers):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163515 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Transfer the non-fast-scrollable region to the UI process for iOS
https://bugs.webkit.org/show_bug.cgi?id=128293

Reviewed by Benjamin Poulain.

Source/WebCore:

Two main changes to support sending the non-fast scrollable region
to the UI process for iOS:

1. Add ScrollingCoordinator::frameViewNonFastScrollableRegionChanged(),
which is called when we've updated the touch event region (this can happen
independenly of layout). When called we just scheduled a scrolling tree
commit with the new region.

2. Avoid thinking that we have a new root node with every remote scrolling
transaction. This was a side-effect of reconstructing the scrolling state
tree in the UI process, and caused us to try to grab a nonFastScrollableRegion
from a node which never had one set.

* WebCore.exp.in:
* page/scrolling/AsyncScrollingCoordinator.cpp:
(WebCore::AsyncScrollingCoordinator::frameViewNonFastScrollableRegionChanged):
* page/scrolling/AsyncScrollingCoordinator.h:
* page/scrolling/ScrollingCoordinator.cpp:
(WebCore::ScrollingCoordinator::computeNonFastScrollableRegion):
* page/scrolling/ScrollingCoordinator.h:
(WebCore::ScrollingCoordinator::frameViewNonFastScrollableRegionChanged):
* page/scrolling/ScrollingStateTree.h:
(WebCore::ScrollingStateTree::setHasNewRootStateNode):
* page/scrolling/ScrollingTree.cpp:
(WebCore::ScrollingTree::commitNewTreeState):
(WebCore::ScrollingTree::isPointInNonFastScrollableRegion):
* page/scrolling/ScrollingTree.h:

Source/WebKit2:

Two main changes to support sending the non-fast scrollable region
to the UI process for iOS:

1. Add ScrollingCoordinator::frameViewNonFastScrollableRegionChanged(),
which is called when we've updated the touch event region (this can happen
independenly of layout). When called we just scheduled a scrolling tree
commit with the new region.

2. Avoid thinking that we have a new root node with every remote scrolling
transaction. This was a side-effect of reconstructing the scrolling state
tree in the UI process, and caused us to try to grab a nonFastScrollableRegion
from a node which never had one set.

Now that we have the non-fast scrollable region in the UI process, we can
use it to avoid sending sync messages to the web process.

* Shared/Scrolling/RemoteScrollingCoordinatorTransaction.cpp:
(ArgumentCoder<ScrollingStateScrollingNode>::encode): Encode hasNewRootNode.
(ArgumentCoder<ScrollingStateScrollingNode>::decode): Decode hasNewRootNode and set it on
the state tree.
(WebKit::RemoteScrollingCoordinatorTransaction::encode): Encode the nonFastScrollableRegion
now that we can encode Regions.
(WebKit::RemoteScrollingCoordinatorTransaction::decode): Decode the nonFastScrollableRegion
now that we can decode Regions.
* UIProcess/Scrolling/RemoteScrollingCoordinatorProxy.cpp:
(WebKit::RemoteScrollingCoordinatorProxy::isPointInNonFastScrollableRegion):
* UIProcess/Scrolling/RemoteScrollingCoordinatorProxy.h:
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::handleTouchEvent): If we're not in the non-fast scrollable region,
don't both sending touch events to the web process.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@163516 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make FTL OSR entry something we only try after we've already compiled the function with the FTL and it still got stuck in a loop after that without ever returning like a sensible function oughta have
https://bugs.webkit.org/show_bug.cgi?id=128234

Reviewed by Geoffrey Garen.
        
Use DFG::JITCode::osrEntryRetry as a counter to decide when to invoke OSR entry. That
comes into play only after we've done a replacement compile.
        
This appears to still give us a speed-up on the kinds of things that OSR entry is good
for, while also eliminating pointless OSR entry compilations on other things.

* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::JITCode):
* dfg/DFGJITCode.h:
* dfg/DFGOperations.cpp:
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
(JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
* runtime/Options.h:



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