[Win64] Compile error after r165128.
https://bugs.webkit.org/show_bug.cgi?id=129807

Patch by peavo@outlook.com <peavo@outlook.com> on 2014-03-07
Reviewed by Mark Lam.

Source/JavaScriptCore:

* JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.sh:
Check platform environment variable to determine if an assembler file should be generated.

Source/WTF:

* wtf/Platform.h: MSVC does not support computed goto.
Also enabled COMPUTED_GOTO_OPCODES when !ENABLE(LLINT_C_LOOP). This is needed because the ASM LLINT operates like COMPUTED_GOTO_OPCODES,
and relies on the related data structures being defined to support this. On Win32, the platform does not HAVE_COMPUTED_GOTO support,
but does want ENABLE_COMPUTED_GOTO_OPCODES because it uses the ASM LLINT.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165296 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r164847): Pressing the command key while hovering an element causes it to un-hover
https://bugs.webkit.org/show_bug.cgi?id=129872

Reviewed by Tim Horton.

* UIProcess/API/Cocoa/WKViewPrivate.h: Changes in performDictionaryLookupAtCurrentMouseLocation
were also not correct, because the current event could be a keyboard one (Cmd+Ctrl+D).
But this SPI is unused, and can be simply removed.

* UIProcess/API/mac/WKView.mm: (-[WKView _postFakeMouseMovedEventForFlagsChangedEvent:]):
locationInWindow is undefined for keyboard events, so we have to use current location.
Thankfully, there is a method that returns the location in appropriate coordinate
space, unlike +[NSEvent mouseLocation] that we used before.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165297 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebKit: Make it possible to copy WebKit2 headers to WebKit.framework
https://bugs.webkit.org/show_bug.cgi?id=129935

Reviewed by Dan Bernstein.

* WebKit.xcodeproj/project.pbxproj:
Move the migrate headers script out into its own file.

Source/WebKit/mac: Make it possible to copy WebKit2 headers to WebKit.framework
https://bugs.webkit.org/show_bug.cgi?id=129935
<rdar://problem/15920020>

Reviewed by Dan Bernstein.

* MigrateHeaders.make:
Gather a list of public and private WebKit2 headers and filter them against the WEBKIT2_HEADERS list.
The matching headers are copied to the respective Headers or PrivateHeaders directories under WebKit.framework,
and also have their #imports rewritten to reference WebKit instead of WebKit2.

* migrate-headers.sh: Added.
Set up the WEBKIT2_FRAMEWORKS_DIR if needed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165298 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Include CMake into install-dependencies script
https://bugs.webkit.org/show_bug.cgi?id=129909

Patch by Lorenzo Tilve <ltilve@igalia.com> on 2014-03-07
Reviewed by Martin Robinson.

As since r165267 buid-webkit uses CMake by default, the dependency
with 'cmake' package should be introduced.

* gtk/install-dependencies: Ditto.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165299 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Traversal failure in a direct adjacent chain with tail backtracking lacks the path to clear the tail
https://bugs.webkit.org/show_bug.cgi?id=129863

Reviewed by Gavin Barraclough.

Source/WebCore: 

Direct adjacent backtracking use the stack to push the backtracking entry point and recover from there.
In case of traversal failure, their is no point in recovering from the indirect adjancent entry point and
we should clear entry point from the stack (which is the purpose of the tail).

The adjancent tail was missing the part for clearing the stack in one case.

The case with adjancent backtracking inside descendant backtracing was doing everything right. This patch
generalize this code and the correct tail is fully generated by generateAdjacentBacktrackingTail().

JumpToClearAdjacentDescendantTail becomes JumpToClearAdjacentTail, and this new backtracking state is added
to the missing traversal action.

Test: fast/selectors/long-adjacent-backtracking.html

* cssjit/SelectorCompiler.cpp:
(WebCore::SelectorCompiler::solveBacktrackingAction):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateSelectorChecker):
(WebCore::SelectorCompiler::SelectorCodeGenerator::linkFailures):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateAdjacentBacktrackingTail):
(WebCore::SelectorCompiler::SelectorCodeGenerator::generateBacktrackingTailsIfNeeded):

LayoutTests: 

Test the faulty case.

* fast/selectors/long-adjacent-backtracking-expected.txt: Added.
* fast/selectors/long-adjacent-backtracking.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165300 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix the regression introduced by r165288
https://bugs.webkit.org/show_bug.cgi?id=129934

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-03-07
Reviewed by Ryosuke Niwa.

* page/DOMWindow.cpp:
(WebCore::DOMWindow::scrollX):
(WebCore::DOMWindow::scrollY):
We need to return the new value after layout, not the value from the dirty tree.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165301 268f45cc-cd09-0410-ab3c-d52691b4dbfc
MigrateHeaders.make should remove C SPI includes from WebKit2 headers
https://bugs.webkit.org/show_bug.cgi?id=129937
<rdar://problem/15920020>

Reviewed by Tim Horton.

Source/WebKit/mac:

* MigrateHeaders.make:
Add WKPreferences.h to WEBKIT2_HEADERS.
Add a sed rule that deletes all lines that start with a # and contain <WebKit/*Ref.h>.

Source/WebKit2:

* WebKit2.xcodeproj/project.pbxproj:
Make WKPreferences.h and all headers it includes public. Update the post processing of WKBase.h
to account for WKBase.h now being a public header again.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165302 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WebKit2][iOS] Main-frame custom content providers
https://bugs.webkit.org/show_bug.cgi?id=129809

Reviewed by Dan Bernstein.

Re-introduce custom content providers to WebKit2 (removed in r152841), but
for iOS this time.

* UIProcess/API/Cocoa/WKWebView.mm:
(-[WKWebView initWithFrame:configuration:]):
Send the initial MIME types that have custom content providers to the WebProcess.

(-[WKWebView dealloc]):
Unregister our page from the content provider registry.

(-[WKWebView _setHasCustomContentView:loadedMIMEType:]):
Install/uninstall the custom content provider. Create a view, if needed,
based on the class that the registry has associated with the given MIME type.
We unparent the WKContentView while the custom content provider is active,
and re-use the existing WKScrollView to contain the custom content provider.

(-[WKWebView _didFinishLoadingDataForCustomContentProviderWithSuggestedFilename:dataReference:]):
Forward loaded data on to the custom content provider for display.

(-[WKWebView _didCommitLayerTree:WebKit::]):
Assert that we aren't getting layer tree commits while using a custom content provider.

(-[WKWebView viewForZoomingInScrollView:]):
If we're using a custom content provider, its view should be used for zooming
instead of the (unparented) web content view.

(-[WKWebView hasContentView]):
(-[WKWebView scrollViewWillBeginZooming:withView:]):
(-[WKWebView scrollViewWillBeginDragging:]):
(-[WKWebView _didFinishScrolling]):
(-[WKWebView _updateVisibleContentRects]):
If we do not have a parented WKContentView because we are using a custom
content provider, we should not forward scroll view related changes to it.

(-[WKWebView _frameOrBoundsChanged]):
Update the minimum size of the custom content provider if the web view size changes.

* UIProcess/API/Cocoa/WKWebViewConfiguration.mm:
(-[WKWebViewConfiguration copyWithZone:]):
(-[WKWebViewConfiguration _contentProviderRegistry]):
(-[WKWebViewConfiguration _setContentProviderRegistry:]):
* UIProcess/API/Cocoa/WKWebViewConfigurationInternal.h: Added.
Add an internal WKWebViewConfiguration property, the WKWebViewContentProviderRegistry.

* UIProcess/API/Cocoa/WKWebViewInternal.h:

* UIProcess/Cocoa/WKWebViewContentProvider.h: Added.
A minimal protocol for informing custom content providers of changes to
the size of the view, the represented data, and the owning scroll view.

* UIProcess/Cocoa/WKWebViewContentProviderRegistry.h: Added.
* UIProcess/Cocoa/WKWebViewContentProviderRegistry.mm: Added.
(-[WKWebViewContentProviderRegistry addPage:]):
(-[WKWebViewContentProviderRegistry removePage:]):
(-[WKWebViewContentProviderRegistry registerProvider:forMIMEType:]):
(-[WKWebViewContentProviderRegistry providerForMIMEType:]):
(-[WKWebViewContentProviderRegistry mimeTypesWithContentProviders]):
New class, keeps track of a mapping from MIME types to UIViews that
conform to the WKWebViewContentProvider protocol.

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::WebPageProxy):
(WebKit::WebPageProxy::didCommitLoadForFrame):
* UIProcess/WebPageProxy.h:
* UIProcess/WebPageProxy.messages.in:

* UIProcess/PageClient.h:
* UIProcess/ios/PageClientImplIOS.h:
* UIProcess/ios/PageClientImplIOS.mm:
(WebKit::PageClientImpl::PageClientImpl):
(WebKit::PageClientImpl::didCommitLoadForMainFrame):
(WebKit::PageClientImpl::didFinishLoadingDataForCustomContentProvider):
* UIProcess/mac/PageClientImpl.h:
* UIProcess/mac/PageClientImpl.mm:
(WebKit::PageClientImpl::didCommitLoadForMainFrame):
(WebKit::PageClientImpl::didFinishLoadingDataForCustomContentProvider):
Add parameters to didCommitLoadForMainFrame, indicating if we should use
a custom content provider to display the main frame, and what MIME type
was loaded in said frame, and add didFinishLoadingDataForCustomContentProvider.
On iOS, forward these to the WKWebView.
Also, give PageClientImplIOS a reference to the WKWebView.

* UIProcess/ios/WKContentView.mm:
(-[WKContentView initWithFrame:context:WebKit::configuration:WebKit::webView:]):

* WebKit2.xcodeproj/project.pbxproj:
* WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFrame.mm:
(-[WKWebProcessPlugInFrame _hasCustomContentProvider]):
* WebProcess/InjectedBundle/API/Cocoa/WKWebProcessPlugInFramePrivate.h:
Expose whether or not a given frame has a custom content provider to the plug-in.

* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::WebFrameLoaderClient):
(WebKit::WebFrameLoaderClient::hasHTMLView):
(WebKit::WebFrameLoaderClient::dispatchDidCommitLoad):
(WebKit::WebFrameLoaderClient::committedLoad):
(WebKit::WebFrameLoaderClient::finishedLoading):
(WebKit::WebFrameLoaderClient::transitionToCommittedFromCachedFrame):
(WebKit::WebFrameLoaderClient::transitionToCommittedForNewPage):
(WebKit::WebFrameLoaderClient::canCachePage):
* WebProcess/WebCoreSupport/WebFrameLoaderClient.h:
(WebKit::WebFrameLoaderClient::frameHasCustomContentProvider):
Restore WebFrameLoaderClient custom representation code, which ensures
that data is routed correctly (to the UI process, and not to WebCore) and
that we don't try to use the page cache for frames with content providers.

* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::mainFrameHasCustomContentProvider):
(WebKit::WebPage::addMIMETypeWithCustomContentProvider):
(WebKit::WebPage::shouldUseCustomContentProviderForResponse):
(WebKit::WebPage::canShowMIMEType):
* WebProcess/WebPage/WebPage.h:
* WebProcess/WebPage/WebPage.messages.in:
Keep a list of MIME types which can be displayed via custom content providers
in WebPage, which will be pushed down from the registry as new providers
are added. Plug-ins still take precendence over custom content providers.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165303 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] built-product-archive does not handle GTK+ CMake build
https://bugs.webkit.org/show_bug.cgi?id=129941

* BuildSlaveSupport/built-product-archive:
(archiveBuiltProduct): Fix the build by adding support to built-product-archive for
the CMake build.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165304 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS WebKit2] Long-press on a link shows just "Copy".
https://bugs.webkit.org/show_bug.cgi?id=129938
<rdar://problem/16266054>

Reviewed by Benjamin Poulain.

When adding a FIXME comment, I accidentally removed the ! on
the if (!element) condition.

* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::getPositionInformation):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@165305 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Continue hangs when performing for-of over arguments
https://bugs.webkit.org/show_bug.cgi?id=129915

Reviewed by Geoffrey Garen.

Source/JavaScriptCore:

Put the continue label in the right place

* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEnumeration):

LayoutTests:

Add tests

* js/for-of-arguments-continue-hang-expected.txt: Added.
* js/for-of-arguments-continue-hang.html: Added.
* js/script-tests/for-of-arguments-continue-hang.js: Added.
(test):

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