Add initial support for generating the StyleBuilder from CSSPropertyNames.in
https://bugs.webkit.org/show_bug.cgi?id=137910

Reviewed by Andreas Kling.

Add initial support for generating the StyleBuilder from
CSSPropertyNames.in. This is a first step towards getting rid of the
legacy DeprecatedStyleBuilder class and having everything defined in one
place (CSSPropertyNames.in).

This patch updates makeprop.pl script to generate a StyleBuilder.cpp
file that generate a the StyleBuilder::applyProperty() method
implementation using a huge switch statement for all the CSS
properties. With this patch, we are now generating the new StyleBuilder
code for all the "simple" CSS properties (i.e. those that were using
ApplyPropertyDefault<> in DeprecatedStyleBuilder.cpp). I am using a
"NewStyleBuilder" option in CSSPropertyNames.in for properties that
we generate to help with improving incrementally the generator. Once
we are able to generate all properties, this transition option will
do away and become the default.

By default, the generator will make an educated guess for the type
name, the getter, the setter and the initial function of each property.
For example, for the border-collapse property, it will use:
- TypeName: EBorderCollapse (i.e. 'E' + PropertyId)
- Getter: borderCollapse() (i.e. PropertyId with first letter lowercased)
- Setter: setBorderCollapse() (i.e. 'set' + PropertyId)
- Initial: initialBorderCollapse() (i.e. 'initial' + PropertyId)

This works for most properties. For properties that need
special-casing, developers can use the following options in
CSSPropertyNames.in:
- TypeName: Overrides the type name
- Getter: Overrides the getter name
- Setter: Overrides the setter name
- Initial: Overrides the initial function name
- NameForMethods: Overrides the Getter / Setter / Initial function
  names. For e.g. "NameForMethods=OverflowWrap" will use
  "overflowWrap() / setOverflowWrap() / initialOverflowWrap()".

The patch is inspired by the following Blink revision by
<timloh@chromium.org>:
https://src.chromium.org/viewvc/blink?view=rev&revision=150424

No new tests, no behavior change.

* CMakeLists.txt:
* DerivedSources.make:
* WebCore.vcxproj/WebCore.vcxproj:
* WebCore.vcxproj/WebCore.vcxproj.filters:
* WebCore.xcodeproj/project.pbxproj:
* css/CSSPropertyNames.in:
* css/DeprecatedStyleBuilder.cpp:
(WebCore::ApplyPropertyVerticalAlign::createHandler):
(WebCore::ApplyPropertyDisplay::applyInitialValue):
(WebCore::DeprecatedStyleBuilder::DeprecatedStyleBuilder):
* css/StyleBuilder.h: Added.
* css/StyleResolver.cpp:
(WebCore::StyleResolver::adjustRenderStyle):
(WebCore::StyleResolver::applyProperty):
* css/makeprop.pl:
* rendering/style/RenderStyle.h:
Move the initialXXX() methods that were in NonInheritedFlags to
RenderStyle class, with the other initialXXX() methods to facilitate
code generation.

* rendering/style/StyleMultiColData.cpp:
(WebCore::StyleMultiColData::StyleMultiColData):
* rendering/style/StyleRareNonInheritedData.cpp:
(WebCore::StyleRareNonInheritedData::StyleRareNonInheritedData):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175052 268f45cc-cd09-0410-ab3c-d52691b4dbfc
XMLHttpRequest should support attribute responseURL as per latest XHR spec.
https://bugs.webkit.org/show_bug.cgi?id=136938

Patch by Shivakumar JM <shiva.jm@samsung.com> on 2014-10-22
Reviewed by Alexey Proskuryakov.

Source/WebCore:

Tests: http/tests/xmlhttprequest/basic-auth-responseURL.html
       http/tests/xmlhttprequest/cross-origin-redirect-responseURL.html
       http/tests/xmlhttprequest/redirect-credentials-responseURL.html
       http/tests/xmlhttprequest/xmlhttprequest-responseURL.html

XMLHttpRequest should support attribute responseURL

* xml/XMLHttpRequest.cpp:
(WebCore::XMLHttpRequest::responseURL):
* xml/XMLHttpRequest.h:
* xml/XMLHttpRequest.idl:

LayoutTests:

Added test to check responseURL attribute in XMLHttpRequest.

* http/tests/xmlhttprequest/basic-auth-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/basic-auth-responseURL.html: Added.
* http/tests/xmlhttprequest/cross-origin-redirect-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/cross-origin-redirect-responseURL.html: Added.
* http/tests/xmlhttprequest/redirect-credentials-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/redirect-credentials-responseURL.html: Added.
* http/tests/xmlhttprequest/xmlhttprequest-responseURL-expected.txt: Added.
* http/tests/xmlhttprequest/xmlhttprequest-responseURL.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175053 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Win] Mark a number of tests as failing due to <select> bug.
https://bugs.webkit.org/show_bug.cgi?id=137962

* platform/win/TestExpectations:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175054 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Mac][WK2] Fix applicationIsSafari() detection
https://bugs.webkit.org/show_bug.cgi?id=137893

Reviewed by Alexey Proskuryakov.

Source/WebCore:

I noticed when profiling Safari on Mac that we were exercising a code
path we shouldn't because it is meant for other applications that
Safari.

The detection relies on the applicationIsSafari() function in
RuntimeApplicationChecks.cpp. This was in some cases returning false on
my machine even though I was running Safari so I investigated a bit and
noticed that the check relies on the main bundle identifier string and
is doing:
isSafari = mainBundleIsEqualTo("com.apple.Safari")
    || mainBundleIsEqualTo("com.apple.WebProcess");

This WebProcess detection is very unreliable because:
- It matches other apps than Safari's WebProcesses
- The bundle name for the WebProcess is sometimes
"com.apple.WebKit.WebContent" or
"com.apple.WebKit.WebContent.Development".

The solution used in this patch is to move the applicationIsSafari()
check to the UIProcess so that the check actually succeeds reliably.
The call site for applicationIsSafari() was in
ResourceRequest::useQuickLookResourceCachingQuirks(). This match
removes that logic from ResourceRequest and move it to
FrameLoaderClient as only the FrameLoader is interested in this
information. The logic to determine if we should use QuickLook
resource caching quirks is moved to a new QuickLook class under
platform/ as the code needs to be shared between WebKit and WebKit2.
On WebKit2, we make use that code on the UIProcess side and pass
the flag as a parameter when constructing the WebProcess. The flag
is then stored on the WebProcess and queried by WebFrameLoaderClient.

Previously, we would spend ~1% of the WebProcess cpu time (when loading
apple.com) trying to detect if we should use QuickLook resource caching
quirks even though that check was supposed to be disabled and return
early when running Safari.

No new tests, not easily testable.

* WebCore.exp.in:
* WebCore.xcodeproj/project.pbxproj:
* loader/EmptyClients.h:
* loader/FrameLoader.cpp:
(WebCore::FrameLoader::subresourceCachePolicy):
* loader/FrameLoaderClient.h:
* platform/RuntimeApplicationChecks.cpp:
(WebCore::applicationIsSafari):
Remove "com.apple.WebProcess" bundle name matching as this causes false
positives (matches other applications than Safari's WebProcesses) and
it is no longer needed now that applicationIsSafari() is always called
from the UIProcess.

* platform/mac/QuickLookMac.h: Added.
* platform/mac/QuickLookMac.mm: Copied from Source/WebCore/platform/network/mac/ResourceRequestMac.mm.
(WebCore::QuickLookMac::computeNeedsQuickLookResourceCachingQuirks):
* platform/network/cf/ResourceRequest.h:
* platform/network/ios/ResourceRequestIOS.mm:
(WebCore::ResourceRequest::useQuickLookResourceCachingQuirks): Deleted.
* platform/network/mac/ResourceRequestMac.mm:
(WebCore::initQuickLookResourceCachingQuirks): Deleted.
(WebCore::ResourceRequest::useQuickLookResourceCachingQuirks): Deleted.

Source/WebKit/mac:

Provide an implementation for FrameLoaderClient's new
needsQuickLookResourceCachingQuirks() that returns
a static flag initialized using
QuickLookMac::computeNeedsQuickLookResourceCachingQuirks().

* WebCoreSupport/WebFrameLoaderClient.h:
* WebCoreSupport/WebFrameLoaderClient.mm:

Source/WebKit2:

Provide an implementation for FrameLoaderClient's new
needsQuickLookResourceCachingQuirks(), which accesses the flag stored
on the WebProcess, which is initialized upon WebProcess creation.

QuickLookMac::computeNeedsQuickLookResourceCachingQuirks() is called
on UIProcess side so that it works reliably and the flag is passed as
parameter when constructing the WebProcess.

* Shared/WebProcessCreationParameters.cpp:
(WebKit::WebProcessCreationParameters::encode):
(WebKit::WebProcessCreationParameters::decode):
* Shared/WebProcessCreationParameters.h:
* UIProcess/mac/WebContextMac.mm:
(WebKit::WebContext::platformInitializeWebProcess):
* WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:
(WebKit::WebFrameLoaderClient::needsQuickLookResourceCachingQuirks):
* WebProcess/WebCoreSupport/WebFrameLoaderClient.h:
* WebProcess/WebProcess.cpp:
(WebKit::WebProcess::WebProcess):
* WebProcess/WebProcess.h:
(WebKit::WebProcess::needsQuickLookResourceCachingQuirks):
* WebProcess/cocoa/WebProcessCocoa.mm:
(WebKit::WebProcess::platformInitializeWebProcess):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175055 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Win] Mark a number of tests as failing due to white selected text color.
https://bugs.webkit.org/show_bug.cgi?id=137963

* platform/win/TestExpectations:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175056 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Unreviewed EFL gardening.
https://bugs.webkit.org/show_bug.cgi?id=137950

Some tests that are passed in latest build.

Patch by Hunseop Jeong <hs85.jeong@samsung.com> on 2014-10-22

* platform/efl/TestExpectations: Remove passing tests from TestExceptation file.

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