run-webkit-tests should have ability to add description to its JSON output
https://bugs.webkit.org/show_bug.cgi?id=93296

Reviewed by Dirk Pranke.

PerformanceTests: 

Parse description and show it with the WebKit revision on the results page. Also use bar graphs
instead of line graphs since we're not depicting the time series here per arv's suggestion.
Finally, add the ability to adjust y-axis between the adjusted value and 0 (plot even doesn't adjust
y-axis automatically now) by a mouse click.

* resources/results-template.html:

Tools: 

Add --description option.

* Scripts/webkitpy/performance_tests/perftestsrunner.py:
(PerfTestsRunner._parse_args):
(PerfTestsRunner._generate_and_show_results):
(PerfTestsRunner._generate_results_dict):
* Scripts/webkitpy/performance_tests/perftestsrunner_unittest.py:
(test_run_with_description):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124802 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION(124789): EWS errors out because --print option is missing
https://bugs.webkit.org/show_bug.cgi?id=93299

Unreviewed.

The --print option doesn't exist anymore.  Let's try --quiet instead.

* Scripts/webkitpy/tool/steps/runtests.py:
(RunTests.run):
* Scripts/webkitpy/tool/steps/runtests_unittest.py:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124803 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] REGRESSION(r124714): webkit_unit_tests asserts in Debug
https://bugs.webkit.org/show_bug.cgi?id=93297

Patch by Adrienne Walker <enne@google.com> on 2012-08-06
Reviewed by James Robinson.

This is a quick fix to get debug unit tests working again by
implementing a virtual function that has ASSERT_NOT_REACHED in the
base class version.

* tests/ScrollAnimatorNoneTest.cpp:
(MockScrollableArea::scrollPosition):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124804 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Use GraphicsLayerAnimation in LayerTreeCoordinator
https://bugs.webkit.org/show_bug.cgi?id=93147

Reviewed by Kenneth Rohde Christiansen

Allow controlling animations outside of WebCore. This is an intermediate step before moving
to threaded animations.

CoordinatedGraphicsLayer maintains the GraphicsLayerAnimation structures, and applies the
animation interpolation at the right time, before syncing the rest of the layer info and
the visible contents rect.

This also allows sending shorter IPC messages for animated opacity/transform changes,
without the rest of the layer info.

* UIProcess/CoordinatedGraphics/LayerTreeCoordinatorProxy.cpp:
(WebKit::LayerTreeCoordinatorProxy::setLayerAnimatedOpacity):
(WebKit):
(WebKit::LayerTreeCoordinatorProxy::setLayerAnimatedTransform):
* UIProcess/CoordinatedGraphics/LayerTreeCoordinatorProxy.h:
(LayerTreeCoordinatorProxy):
* UIProcess/CoordinatedGraphics/LayerTreeCoordinatorProxy.messages.in:
* UIProcess/CoordinatedGraphics/LayerTreeRenderer.cpp:
(WebKit::LayerTreeRenderer::setAnimatedOpacity):
(WebKit):
(WebKit::LayerTreeRenderer::setAnimatedTransform):
* UIProcess/CoordinatedGraphics/LayerTreeRenderer.h:
(LayerTreeRenderer):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::didChangeAnimatedProperties):
(WebCore):
(WebCore::CoordinatedGraphicsLayer::CoordinatedGraphicsLayer):
(WebCore::CoordinatedGraphicsLayer::syncLayerState):
(WebCore::CoordinatedGraphicsLayer::syncAnimatedProperties):
(WebCore::CoordinatedGraphicsLayer::syncCompositingStateForThisLayerOnly):
(WebCore::CoordinatedGraphicsLayer::computeTransformedVisibleRect):
    account for the animated transform in the visible rect.

(WebCore::CoordinatedGraphicsLayer::addAnimation):
(WebCore::CoordinatedGraphicsLayer::pauseAnimation):
(WebCore::CoordinatedGraphicsLayer::removeAnimation):
(WebCore::CoordinatedGraphicsLayer::animationStartedTimerFired):
(WebCore::CoordinatedGraphicsLayer::setAnimatedTransform):
(WebCore::CoordinatedGraphicsLayer::setAnimatedOpacity):
* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.h:
(CoordinatedGraphicsLayerClient):
(CoordinatedGraphicsLayer):
* WebProcess/WebPage/CoordinatedGraphics/LayerTreeCoordinator.cpp:
(WebKit):
(WebKit::LayerTreeCoordinator::setLayerAnimatedOpacity):
(WebKit::LayerTreeCoordinator::setLayerAnimatedTransform):
* WebProcess/WebPage/CoordinatedGraphics/LayerTreeCoordinator.h:
(LayerTreeCoordinator):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124805 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Testcase LayoutTests/editing/input/editable-container-with-word-wrap-normal.html failing on Mac
https://bugs.webkit.org/show_bug.cgi?id=93287

Patch by Pravin D <pravind.2k4@gmai.com> on 2012-08-06
Reviewed by Ryosuke Niwa.

The testcase uses 'End' keypress event emulation to scroll the caret to the end of the line. As the behavior of 'End' keypress
is platform dependent, replacing it platform independent code.

* editing/input/editable-container-with-word-wrap-normal-expected.txt:
* editing/input/editable-container-with-word-wrap-normal.html:
  Replaced 'End' keypress event with testRunner's execCommand() to make testcase behavior independent of platform.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124806 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add twiz@{chromium|google}.org to the set of non-committer contributors.
https://bugs.webkit.org/show_bug.cgi?id=93288

Patch by Jeff Timanus <twiz@chromium.org> on 2012-08-06
Reviewed by Adam Barth.

* Scripts/webkitpy/common/config/committers.py:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124807 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Default sizes for input-text and text-area are different when running DRT/WTR
https://bugs.webkit.org/show_bug.cgi?id=91990

Patch by Luciano Wolf <luciano.wolf@openbossa.org> on 2012-08-06
Reviewed by Kenneth Rohde Christiansen.

Source/WebKit2:

WTR wasn't using the proper font types provided by testfonts directory.
The same approach as DRT was applied and now it takes info from QFont to
update the store variable.

* UIProcess/qt/WebPreferencesQt.cpp:
(WebKit::setStringValueIfInUserDefaults):
(WebKit):
(WebKit::WebPreferences::platformInitializeStore):

Tools:

Initializing TestFonts information into WTR binary. Doing it
later leads to wrong font names usage (Dejavu Serif instead
of Liberation Serif).

* WebKitTestRunner/Target.pri:
* WebKitTestRunner/qt/main.cpp:
(main):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124808 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove NRWT --shard-ref-tests
https://bugs.webkit.org/show_bug.cgi?id=91539

This is basically a revert of "[Chromium-Android] Run ref tests together to avoid expensive driver restarts"
(https://bugs.webkit.org/show_bug.cgi?id=91533, http://trac.webkit.org/changeset/122914),
with some conflicts resolved (because of refactory of Manager/LayoutTestRunner/Sharder classes).

Reviewed by Dirk Pranke.

* Scripts/webkitpy/layout_tests/controllers/layout_test_runner.py:
(LayoutTestRunner.run_tests):
(Sharder.shard_tests):
(Sharder._shard_in_two):
(Sharder._shard_by_directory):
* Scripts/webkitpy/layout_tests/controllers/layout_test_runner_unittest.py:
(SharderTests):
(SharderTests.get_test_input):
(SharderTests.get_shards):
(SharderTests.test_shard_by_dir):
(SharderTests.test_shard_in_two):
* Scripts/webkitpy/layout_tests/controllers/manager.py:
(Manager._test_input_for_file):
(Manager._test_is_slow):
* Scripts/webkitpy/layout_tests/port/chromium_android.py:
(ChromiumAndroidPort.__init__):
* Scripts/webkitpy/layout_tests/run_webkit_tests.py:
(parse_args):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124809 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium-Android] Virtual test suites fail
https://bugs.webkit.org/show_bug.cgi?id=92515

Reviewed by Dirk Pranke.

The failure is because our bypassing of DriverProxy.
Repeat the logic of virtual tests in DriverProxy in ChromiumAndroidDriver
and restart DRT when the command line changes.

* Scripts/webkitpy/layout_tests/port/chromium_android.py:
(ChromiumAndroidDriver.__init__):
(ChromiumAndroidDriver.cmd_line): Added comments about why we override this and have _drt_cmd_line().
(ChromiumAndroidDriver.run_test): Repeat the logic of virtual tests in DriverProxy.
(ChromiumAndroidDriver.start): Restart DRT when the command line changes.
(ChromiumAndroidDriver._start_once):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124810 268f45cc-cd09-0410-ab3c-d52691b4dbfc
https://bugs.webkit.org/show_bug.cgi?id=93199
REGRESSION (r124489): Crash in FrameView::scrollContentsFastPath when 
scrolling Facebook and Google image search
-and corresponding-
<rdar://problem/12035066>

Reviewed by Anders Carlsson.

As the comment in setShouldUpdateScrollLayerPositionOnMainThread() 
indicates, the goal of adding a call to 
updateMainFrameScrollPositionAndScrollLayerPosition() within that 
function was just to make sure the layer position was up-to-date 
since that is what is not kept up to date when scrolling is happening 
on the scrolling thread. So I'm fixing this crash by having that code 
ONLY update the layer position instead of also updating the scroll 
position, since it was updating the scroll position that led to this 
crash.

New function updateMainFrameScrollLayerPosition() will update JUST 
the layer position.
* page/scrolling/ScrollingCoordinator.h:
(ScrollingCoordinator):        
* page/scrolling/ScrollingCoordinator.cpp:
(WebCore::ScrollingCoordinator::updateMainFrameScrollLayerPosition):

Update just the layer position here instead of the layer position and 
the scroll position.
(WebCore)::



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124811 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] WebTouchCandidatesInfo should be part of the Client API
https://bugs.webkit.org/show_bug.cgi?id=93088

Reviewed by Eric Seidel.

Source/Platform:

All the input related interfaces are part of the client (rather than
the platform) part of the API. This patch moves WebTouchCandidatesInfo
to the client part of the API.

* Platform.gypi:
* chromium/public/WebTouchCandidatesInfo.h: Removed.

Source/WebKit/chromium:

* WebKit.gyp:
* public/WebTouchCandidatesInfo.h: Copied from Source/Platform/chromium/public/WebTouchCandidatesInfo.h.
* src/WebViewImpl.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124813 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Out-of-process plug-ins should support asynchronous initialization
<rdar://problem/10598594> and https://bugs.webkit.org/show_bug.cgi?id=92919

Reviewed by Anders Carlsson.

Source/WebKit2:

If a plug-in has been deemed capable of asynchronous initialization when run out of process...
...then do that!

Add flags to communicate that this plugin create is meant to create a plug-in already requested asynchronously and
to include whether or not the initialize call should include an artificial delay (for testing):
* PluginProcess/PluginCreationParameters.cpp:
(WebKit::PluginCreationParameters::PluginCreationParameters):
(WebKit::PluginCreationParameters::encode):
(WebKit::PluginCreationParameters::decode):
* PluginProcess/PluginCreationParameters.h:
(PluginCreationParameters):

Add a flag for the UI Process to tell the PluginProcess that it supports asynchronous initialization:
* Shared/Plugins/PluginProcessCreationParameters.cpp:
(WebKit::PluginProcessCreationParameters::PluginProcessCreationParameters):
(WebKit::PluginProcessCreationParameters::encode):
(WebKit::PluginProcessCreationParameters::decode):
* Shared/Plugins/PluginProcessCreationParameters.h:
(PluginProcessCreationParameters):

Allow the UI Process to pass along whether the plug-on supports asynchronous initialization:
* UIProcess/Plugins/PluginProcessProxy.cpp:
(WebKit::PluginProcessProxy::pluginProcessCrashedOrFailedToLaunch):
(WebKit::PluginProcessProxy::didCreateWebProcessConnection):
* UIProcess/Plugins/PluginProcessProxy.h:
(PluginProcessProxy):
* UIProcess/Plugins/mac/PluginProcessProxyMac.mm:
(WebKit::PluginProcessProxy::platformInitializePluginProcess):
* UIProcess/WebProcessProxy.messages.in:

Allow the Plugin Process to pass whether or not it supports asynchronous initialization, originally determined
in the UI Process, along to the WebProcess:
* PluginProcess/PluginProcess.cpp:
(WebKit::PluginProcess::PluginProcess):
(WebKit::PluginProcess::initializePluginProcess):
(WebKit::PluginProcess::createWebProcessConnection):
* PluginProcess/PluginProcess.h:
(PluginProcess):
* UIProcess/Plugins/PluginProcessProxy.messages.in:

Add a flag so PluginProcessConnections remember whether or not they support asynchronous initialization:
* WebProcess/Plugins/PluginProcessConnection.cpp:
(WebKit::PluginProcessConnection::PluginProcessConnection):
(WebKit::PluginProcessConnection::setSupportsAsynchronousPluginInitialization):
(WebKit):
* WebProcess/Plugins/PluginProcessConnection.h:
(WebKit::PluginProcessConnection::create):
(WebKit::PluginProcessConnection::supportsAsynchronousPluginInitialization):
(PluginProcessConnection):

Create PluginProcessConnections with the flag passed down from the PluginProcess about whether or not they
support asynchronous initialization:
* WebProcess/Plugins/PluginProcessConnectionManager.cpp:
(WebKit::PluginProcessConnectionManager::getPluginProcessConnection):

Responding to messages from the WebProcess, most of the heavy decision making in asynchronous initialization is here:
* PluginProcess/WebProcessConnection.cpp:
(WebKit::asynchronousInstanceIDsToIgnore): A set of instance IDs to *not* create asynchronously later because we know
  we no longer need to.
(WebKit):
(WebKit::WebProcessConnection::didReceiveMessage):
(WebKit::WebProcessConnection::destroyPlugin): If the plug-in doesn't exist but is awaiting asynchronous creation, flag
  this instance ID in the "asynchronous ignore set".
(WebKit::WebProcessConnection::createPluginInternal): Renamed from createPlugin, actually does the plug-in creation.
(WebKit::WebProcessConnection::createPlugin): Adds the instance ID to the "asynchronous ignore set" then calls createPluginInternal.
(WebKit::WebProcessConnection::createPluginAsynchronously): If the instance ID is in the "asynchronous ignore set", remove it from the
  set and do nothing else. Otherwise, perform the initialization and then send the asynchronous result back to the WebProcess.
* PluginProcess/WebProcessConnection.h:
(WebProcessConnection):
* PluginProcess/WebProcessConnection.messages.in:

Add helpers for asynchronous initialization that all plug-in types must implement:
* WebProcess/Plugins/Plugin.h:
(Plugin):

Add helpers for asynchronous initialization that plug-in controllers can override:
* WebProcess/Plugins/PluginController.h:
(PluginController):
(WebKit::PluginController::asynchronousPluginInitializationEnabled):
(WebKit::PluginController::asynchronousPluginInitializationEnabledForAllPlugins):
(WebKit::PluginController::artificialPluginInitializationDelayEnabled):

Give PluginProxys the ability to initialize either asynchronously or synchronously, and also the ability to synchronously
wait for previously asynchronous initialization (in case their PluginScriptObject is required):
* WebProcess/Plugins/PluginProxy.cpp:
(WebKit::PluginProxy::PluginProxy):
(WebKit::PluginProxy::initialize): Store the plugin creation parameters as a member, and decide whether to try synchronous
  or asynchronous initialization.
(WebKit):
(WebKit::PluginProxy::canInitializeAsynchronously): Answer based on preferences and what the PluginProcessConnection says
  that it supports.
(WebKit::PluginProxy::waitForAsynchronousInitialization): Synchronously wait on initialization when asynchronous initialization
  was previously requested.
(WebKit::PluginProxy::initializeSynchronously):
(WebKit::PluginProxy::didCreatePlugin): Double-check that we're still expecting asynchronous initialization, then call
  through to didCreatePluginInternal.
(WebKit::PluginProxy::didCreatePluginInternal): Handle completion of initialization (both synchronously and asynchronously)
(WebKit::PluginProxy::didFailToCreatePlugin): Double-check that we're still expecting asynchronous initialization, then call
  through to didFailToCreatePluginInternal.
(WebKit::PluginProxy::didFailToCreatePluginInternal): Handle failure to initialize (both synchronously and asynchronously)
(WebKit::PluginProxy::destroy):
* WebProcess/Plugins/PluginProxy.h:
(WebKit):
(WebKit::PluginProxy::isInitializingAsynchronously):
(PluginProxy):
* WebProcess/Plugins/PluginProxy.messages.in:

* WebProcess/Plugins/PluginView.cpp:
(WebKit::PluginView::PluginView):
(WebKit::PluginView::~PluginView): Always destroy the plug-in even if it hasn't been initialized yet, as it might be initializing
  right now.
(WebKit::PluginView::initializePlugin): Don't handle the result of initialization immediately. Break that out in to two
  methods that will be called later.
(WebKit):
(WebKit::PluginView::didFailToInitializePlugin):
(WebKit::PluginView::didInitializePlugin):
(WebKit::PluginView::scriptObject): If we truly need the script object, then wait for a synchronous initialization of the plug-in.
(WebKit::PluginView::asynchronousPluginInitializationEnabled):
(WebKit::PluginView::asynchronousPluginInitializationEnabledForAllPlugins):
(WebKit::PluginView::artificialPluginInitializationDelayEnabled):
* WebProcess/Plugins/PluginView.h:
(PluginView):

These methods shouldn't be called in the PluginProcess, only in the WebProcess:
* PluginProcess/PluginControllerProxy.cpp:
(WebKit::PluginControllerProxy::didInitializePlugin):
(WebKit):
(WebKit::PluginControllerProxy::didFailToInitializePlugin):
* PluginProcess/PluginControllerProxy.h:
(PluginControllerProxy):

NetscapePlugin is for in-process plug-ins:
* WebProcess/Plugins/Netscape/NetscapePlugin.h:
(NetscapePlugin):
(WebKit::NetscapePlugin::waitForAsynchronousInitialization):
(WebKit::NetscapePlugin::isInitializingAsynchronously):

Built-in PDFView is currently only in-process:
* WebProcess/Plugins/PDF/BuiltInPDFView.h:
(BuiltInPDFView):
(WebKit::BuiltInPDFView::waitForAsynchronousInitialization):
(WebKit::BuiltInPDFView::isInitializingAsynchronously):

Tools:

Add a plug-in with an NPP_New that takes 550ms (a reasonable trade-off between a solid test and a slow running test)
for testing asynchronous plug-in initialization.

* DumpRenderTree/DumpRenderTree.xcodeproj/project.pbxproj:
* DumpRenderTree/TestNetscapePlugIn/Tests/SlowNPPNew.cpp: Copied from Source/WebKit2/Shared/Plugins/PluginProcessCreationParameters.h.
(SlowNPPNew):
(SlowNPPNew::SlowNPPNew):
(SlowNPPNew::NPP_New):

LayoutTests:

Add tests to make sure a plug-in with a long running NPP_New does not block the web thread.

* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization-expected.txt: Added.
* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization-multiple-expected.txt: Added.
* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization-multiple.html: Added.
* platform/mac-wk2/plugins/slow/asynchronous-plugin-initialization.html: Added.
* platform/mac-wk2/plugins/slow/resources/asynchronous-plugin-initialization-multiple-finish.html: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124815 268f45cc-cd09-0410-ab3c-d52691b4dbfc
GraphicsLayerAnimation shouldn't use HashMap<String>
https://bugs.webkit.org/show_bug.cgi?id=93284

Reviewed by Kenneth Rohde Christiansen.

Source/WebCore:

Use a vector containing all the animations instead of a map of String to Vector.
The HashMap contains very few elements, which makes it inefficient relatively to a vector.
This has been shown to be a bottleneck in valgrind.

Covered by existing animation tests.

* platform/graphics/GraphicsLayerAnimation.cpp:
(WebCore::GraphicsLayerAnimation::GraphicsLayerAnimation):
(WebCore::GraphicsLayerAnimations::hasActiveAnimationsOfType):
(WebCore::GraphicsLayerAnimations::hasRunningAnimations):
(WebCore::GraphicsLayerAnimations::add):
(WebCore::GraphicsLayerAnimations::pause):
(WebCore::GraphicsLayerAnimations::remove):
(WebCore::GraphicsLayerAnimations::apply):
* platform/graphics/GraphicsLayerAnimation.h:
(GraphicsLayerAnimation):
(WebCore::GraphicsLayerAnimation::name):
(GraphicsLayerAnimations):
* platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:
(WebCore::GraphicsLayerTextureMapper::addAnimation):

Source/WebKit2:

Apply the changes to GraphicsLayerAnimation API.

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::addAnimation):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124816 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unify JSC date and time formating functions
https://bugs.webkit.org/show_bug.cgi?id=92282

Reviewed by Geoffrey Garen.

Replace the existing functions for formating GregorianDateTime
with one single function. This removes some code duplications
in DatePrototype and is a preperation to fix encoding issues,
since we can add UChar* values to the resulting string now.

* runtime/DateConstructor.cpp:
(JSC::callDate):
* runtime/DateConversion.cpp:
(JSC::formatDateTime):
* runtime/DateConversion.h:
(JSC):
* runtime/DatePrototype.cpp:
(JSC::formateDateInstance):
(JSC::dateProtoFuncToString):
(JSC::dateProtoFuncToUTCString):
(JSC::dateProtoFuncToDateString):
(JSC::dateProtoFuncToTimeString):
(JSC::dateProtoFuncToGMTString):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124817 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Shaders] Parse mix function
https://bugs.webkit.org/show_bug.cgi?id=90101

Patch by Max Vujovic <mvujovic@adobe.com> on 2012-08-06
Reviewed by Dirk Schulze.

Source/WebCore:

Parse the mix function syntax for CSS Shaders as defined in the Filter Effects spec:
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

The fragment shader argument of the custom filter function can now be a mix function with
the following syntax:
mix(<uri> [ <blend-mode> || <alpha-compositing> ]?)

For example:
-webkit-filter: custom(url(shader.vert) mix(url(shader.frag multiply source-over))

The Filter Effects spec references the Compositing and Blending spec, which defines the
supported blend modes and alpha compositing modes.

Blend modes:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend-mode

This patch adds all of the blend modes in the spec.

Alpha compositing modes:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#alpha-compositing

This patch does not add any new CSS values for alpha compositing. Currently, we parse the
values that are the same between the spec and the -webkit-background-composite property,
including:
    clear
    copy
    source-over
    source-in
    source-out
    source-atop
    destination-over
    destination-in
    destination-out
    destination-atop
    xor

In the future, we may need to add the following CSS values for alpha compositing:
    lighter
    destination

This is currently under discussion on the www-style mailing list:
http://lists.w3.org/Archives/Public/www-style/2012Aug/0123.html

No new test files. Add test cases in:
    css3/filters/script-tests/custom-filter-property-computed-style.js:
    css3/filters/script-tests/custom-filter-property-parsing-invalid.js:
    css3/filters/script-tests/custom-filter-property-parsing.js:

* GNUmakefile.list.am:
* Target.pri:
* WebCore.gypi:
* WebCore.vcproj/WebCore.vcproj:
* WebCore.xcodeproj/project.pbxproj:
* css/CSSComputedStyleDeclaration.cpp:
(WebCore::CSSComputedStyleDeclaration::valueForFilter):
* css/CSSParser.cpp:
(WebCore::CSSParser::isBlendMode):
(WebCore):
(WebCore::CSSParser::isCompositeOperator):
(WebCore::CSSParser::parseMixFunction):
(WebCore::CSSParser::parseCustomFilter):
* css/CSSParser.h:
(WebCore):
* css/CSSParserValues.h:
(WebCore::CSSParserValueList::currentIndex):
* css/CSSPrimitiveValueMappings.h:
(WebCore::CSSPrimitiveValue::CSSPrimitiveValue):
(WebCore):
(WebCore::CSSPrimitiveValue::operator BlendMode):
* css/CSSValue.cpp:
(WebCore::CSSValue::reportMemoryUsage):
(WebCore::CSSValue::cssText):
(WebCore::CSSValue::destroy):
(WebCore::CSSValue::cloneForCSSOM):
* css/CSSValue.h:
(WebCore::CSSValue::isWebKitCSSMixFunctionValue):
(CSSValue):
* css/CSSValueKeywords.in:
* css/StyleResolver.cpp:
(WebCore::StyleResolver::collectMatchingRulesForList):
* css/WebKitCSSMixFunctionValue.cpp: Added.
(WebCore):
(WebCore::WebKitCSSMixFunctionValue::WebKitCSSMixFunctionValue):
(WebCore::WebKitCSSMixFunctionValue::customCssText):
(WebCore::WebKitCSSMixFunctionValue::cloneForCSSOM):
(WebCore::WebKitCSSMixFunctionValue::reportDescendantMemoryUsage):
* css/WebKitCSSMixFunctionValue.h: Added.
(WebCore):
(WebKitCSSMixFunctionValue):
(WebCore::WebKitCSSMixFunctionValue::create):
* platform/graphics/GraphicsTypes.h:
* platform/graphics/filters/CustomFilterProgram.cpp:
(WebCore::CustomFilterProgram::CustomFilterProgram):
* platform/graphics/filters/CustomFilterProgram.h:
(WebCore::CustomFilterProgramMixSettings::CustomFilterProgramMixSettings):
(CustomFilterProgramMixSettings):
(WebCore):
* rendering/style/StyleCustomFilterProgram.h:
(WebCore::StyleCustomFilterProgram::create):
(WebCore::StyleCustomFilterProgram::StyleCustomFilterProgram):

LayoutTests:

Add tests for custom filter mix function parsing as defined in the Filter Effects spec:
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction

Remove some mac-wk2 and chromium expectations because they are the same as the general
expectations.

* css3/filters/custom/custom-filter-property-computed-style-expected.txt:
* css3/filters/custom/custom-filter-property-parsing-expected.txt:
* css3/filters/custom/custom-filter-property-parsing-invalid-expected.txt:
* css3/filters/script-tests/custom-filter-property-computed-style.js:
* css3/filters/script-tests/custom-filter-property-parsing-invalid.js:
* css3/filters/script-tests/custom-filter-property-parsing.js:
* platform/chromium/css3/filters/custom/custom-filter-property-computed-style-expected.txt:
* platform/chromium/css3/filters/custom/custom-filter-property-parsing-expected.txt:
* platform/chromium/css3/filters/custom/custom-filter-property-parsing-invalid-expected.txt: Removed.
* platform/mac-wk2/css3/filters/custom/custom-filter-property-computed-style-expected.txt: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124820 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WIN] Remove dependency on pthread from MachineStackMarker
https://bugs.webkit.org/show_bug.cgi?id=68429

Reviewed by Geoffrey Garen.

Windows has no support for calling a destructor for thread specific data.
Since we need more control over creating and deleting thread specific keys
we can not simply extend WTF::ThreadSpecific with this functionality.

All thread specific keys created via the new API get stored in a list.
After a thread function finished we iterate over this list and call
the registered destructor for every item if needed.

Source/JavaScriptCore:

* heap/MachineStackMarker.cpp:  Use the new functions instead of pthread directly.
(JSC::MachineThreads::~MachineThreads):
(JSC::MachineThreads::makeUsableFromMultipleThreads):
(JSC::MachineThreads::addCurrentThread):
* heap/MachineStackMarker.h:
(MachineThreads):

Source/WTF:

* wtf/ThreadSpecific.h:
(WTF):
(WTF::threadSpecificKeyCreate): Added wrapper around pthread_key_create.
(WTF::threadSpecificKeyDelete): Added wrapper around pthread_key_delete.
(WTF::threadSpecificSet): Added wrapper around pthread_setspecific.
(WTF::threadSpecificGet): Added wrapper around pthread_getspecific.
* wtf/ThreadSpecificWin.cpp:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124823 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CSS Exclusions] Add a command-line flag to enable / disable exclusions
https://bugs.webkit.org/show_bug.cgi?id=91420

Patch by Bear Travis <betravis@adobe.com> on 2012-08-06
Reviewed by Dimitri Glazkov.

Adding the interface code to expose the css exclusions runtime flag to
Chromium.

* public/WebRuntimeFeatures.h:
(WebRuntimeFeatures): Adding getters/setters for cssExclusions
* src/WebRuntimeFeatures.cpp:
(WebKit::WebRuntimeFeatures::enableCSSExclusions):
(WebKit):
(WebKit::WebRuntimeFeatures::isCSSExclusionsEnabled):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124824 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r124816.
http://trac.webkit.org/changeset/124816
https://bugs.webkit.org/show_bug.cgi?id=93311

made some tests crash (Requested by noamr on #webkit).

Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-08-06

Source/WebCore:

* platform/graphics/GraphicsLayerAnimation.cpp:
(WebCore::GraphicsLayerAnimation::GraphicsLayerAnimation):
(WebCore::GraphicsLayerAnimations::hasActiveAnimationsOfType):
(WebCore::GraphicsLayerAnimations::hasRunningAnimations):
(WebCore::GraphicsLayerAnimations::add):
(WebCore::GraphicsLayerAnimations::pause):
(WebCore::GraphicsLayerAnimations::apply):
* platform/graphics/GraphicsLayerAnimation.h:
(GraphicsLayerAnimation):
(GraphicsLayerAnimations):
(WebCore::GraphicsLayerAnimations::remove):
* platform/graphics/texmap/GraphicsLayerTextureMapper.cpp:
(WebCore::GraphicsLayerTextureMapper::addAnimation):

Source/WebKit2:

* WebProcess/WebPage/CoordinatedGraphics/CoordinatedGraphicsLayer.cpp:
(WebCore::CoordinatedGraphicsLayer::addAnimation):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124825 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Cleanup configure.ac build options output
https://bugs.webkit.org/show_bug.cgi?id=93245

Patch by Xan Lopez <xlopez@igalia.com> on 2012-08-06
Reviewed by Laszlo Gombos.

Remove duplicated elements, sort alphabetically.

* configure.ac: ditto.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@124826 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Clear out the TileCache backpointer for all tile layers when the tile cache is destroyed
https://bugs.webkit.org/show_bug.cgi?id=93317
<rdar://problem/11566543>

Reviewed by Dean Jackson.

It seems that in some rare cases, the tile cache layer can be destroyed in the same transaction as tile layers
are being asked to paint. Make sure to null out the TileCache back pointer for all layers in the TileCache destructor.

* platform/graphics/ca/mac/TileCache.mm:
(WebCore::TileCache::~TileCache):

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