[GStreamer] 0.11 build broken (again)
https://bugs.webkit.org/show_bug.cgi?id=93474

Reviewed by Martin Robinson.

.:

* configure.ac: Disable media-stream build if GStreamer 0.11
support is enabled, due to farstream-0.1 still messing up with
gstreamer-0.10 include path.

Source/WebCore:

Adapt the GStreamer media player backend to the latest GStreamer
0.11 API changes.

* platform/graphics/gstreamer/GRefPtrGStreamer.cpp:
(WTF::adoptGRef):
* platform/graphics/gstreamer/GStreamerVersioning.cpp:
(gstObjectIsFloating):
* platform/graphics/gstreamer/GStreamerVersioning.h:
* platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
(StreamingClient::didReceiveResponse):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125041 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Remove All Custom binding code for TypedArray.
https://bugs.webkit.org/show_bug.cgi?id=93371

Patch by Vineet Chaudhary <rgf748@motorola.com> on 2012-08-08
Reviewed by Kentaro Hara.

Removing Custom bindings completely with help of [TypedArray] attribute.

Tests: TestTypedArray.idl
There should not be any behavioral change and all tests should pass.

* GNUmakefile.list.am: Removed Custom files.
* Target.pri: Ditto.
* UseJSC.cmake: Ditto.
* UseV8.cmake: Ditto.
* WebCore.gypi: Ditto.
* WebCore.xcodeproj/project.pbxproj: Ditto.
* bindings/js/JSBindingsAllInOne.cpp: Ditto.
* bindings/js/JSFloat32ArrayCustom.cpp: Removed.
* bindings/js/JSFloat64ArrayCustom.cpp: Removed.
* bindings/js/JSInt16ArrayCustom.cpp: Removed.
* bindings/js/JSInt32ArrayCustom.cpp: Removed.
* bindings/js/JSInt8ArrayCustom.cpp: Removed.
* bindings/js/JSUint16ArrayCustom.cpp: Removed.
* bindings/js/JSUint32ArrayCustom.cpp: Removed.
* bindings/js/JSUint8ArrayCustom.cpp: Removed.
* bindings/js/JSUint8ClampedArrayCustom.cpp: Removed.
* bindings/scripts/CodeGeneratorCPP.pm:
(GenerateHeader): Skip implementaion for TypedArray.
(GenerateImplementation): Skip implementaion for TypedArray.
* bindings/scripts/CodeGeneratorGObject.pm:
(GenerateFunction): Skip implementaion for TypedArray.
* bindings/scripts/CodeGeneratorJS.pm:
(GenerateImplementation): Generates binding for set() call.
(GenerateConstructorDefinition): ConstructorTemplate implementation for TypedArray.
* bindings/scripts/CodeGeneratorObjC.pm:
(GenerateHeader): Skip implementaion for TypedArray.
(GenerateImplementation): Skip implementaion for TypedArray.
* bindings/scripts/CodeGeneratorV8.pm:
(GenerateFunctionCallback): Generates binding for setCallback().
(GenerateTypedArrayConstructorCallback): Generates binding for constructorCallback().
(GenerateImplementation):
* bindings/scripts/IDLAttributes.txt: Support ConstructorTemplate for TypedArray as well.
* bindings/scripts/test/JS/JSFloat64Array.cpp: Binding tests results.
(WebCore::toJS):
(WebCore::JSFloat64Array::indexSetter):
(WebCore::JSFloat64ArrayConstructor::getConstructData):
(WebCore::jsFloat64ArrayPrototypeFunctionFoo):
(WebCore::jsFloat64ArrayPrototypeFunctionSet):
* bindings/scripts/test/JS/JSFloat64Array.h: Binding tests results.
* bindings/scripts/test/TestTypedArray.idl: Binding tests.
* bindings/scripts/test/V8/V8Float64Array.cpp: Binding tests results.
(WebCore::Float64ArrayV8Internal::setCallback):
(Float64ArrayV8Internal):
(WebCore):
(WebCore::V8Float64Array::constructorCallback):
(WebCore::ConfigureV8Float64ArrayTemplate):
* bindings/v8/custom/V8Float32ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Float64ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Int16ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Int32ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Int8ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Uint16ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Uint32ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Uint8ArrayCustom.cpp: Removed.
* bindings/v8/custom/V8Uint8ClampedArrayCustom.cpp: Removed.
* html/canvas/Float32Array.idl: Using [ConstructorTemplate = TypedArray] instead of custom implementaion.
* html/canvas/Float64Array.idl: Ditto.
* html/canvas/Int16Array.idl: Ditto.
* html/canvas/Int32Array.idl: Ditto.
* html/canvas/Int8Array.idl: Ditto.
* html/canvas/Uint16Array.idl: Ditto.
* html/canvas/Uint32Array.idl: Ditto.
* html/canvas/Uint8Array.idl: Ditto.
* html/canvas/Uint8ClampedArray.idl: Ditto.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125042 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, build fix after r125041.

* platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:
(StreamingClient::didReceiveResponse): Fix arguments order of the
notifyGstTagsOnPad() call.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125043 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Chromium] Skia assert triggered by custom filter unmultiplied results
https://bugs.webkit.org/show_bug.cgi?id=92758

Reviewed by Dean Jackson.

Source/WebCore:

The FECustomFilter (which renders the CSS Shaders) used premultiplied colors for both input and ouput.
The problem with that is that some shaders do not pre-multiply the values and the reality is that
we cannot trust the shader to do that. The easy way would be to use only unpremultiplied colors and do the
computation in C++ code. This will be changed when the mix blending is implemented to do that in the shader itself.

No new tests, just updated existing tests to take unpremultiplied colors instead.

* platform/graphics/filters/FECustomFilter.cpp:
(WebCore::FECustomFilter::platformApplySoftware):

LayoutTests:

Updated the shaders to output un-premultiplied colors. Also, updated the output results where needed.

* css3/filters/custom/custom-filter-shader-cache-expected.png:
* css3/filters/custom/effect-color-check-expected.png:
* css3/filters/custom/effect-custom-combined-missing-expected.png:
* css3/filters/custom/effect-custom-expected.png:
* css3/filters/custom/effect-custom-parameters-expected.png:
* css3/filters/custom/filter-repaint-custom-expected.png:
* css3/filters/custom/missing-custom-filter-shader-expected.png:
* css3/filters/resources/color-add.fs:
* css3/filters/resources/color-fill.fs:
* platform/chromium/TestExpectations: Disabled the following tests on Windows. They need a rebaseline.
* platform/chromium-linux/css3/filters/custom/effect-color-check-expected.png:
* platform/chromium-linux/css3/filters/custom/effect-custom-combined-missing-expected.png:
* platform/chromium-linux/css3/filters/custom/effect-custom-parameters-expected.png:
* platform/chromium-mac/css3/filters/custom/effect-color-check-expected.png:
* platform/chromium-mac/css3/filters/custom/effect-custom-combined-missing-expected.png:
* platform/chromium-mac/css3/filters/custom/effect-custom-parameters-expected.png:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125044 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GStreamer] media/media-continues-playing-after-replace-source.html fails
https://bugs.webkit.org/show_bug.cgi?id=86310

Reviewed by Eric Carlson.

Source/WebCore:

Reset the player's network and ready states, this allows the media
player client to potentially emit a timeupdate event while the new
location is being loaded. States are synchronized again after the
pipeline pre-rolled.

No new tests but fixes
media/media-continues-playing-after-replace-source.html

* platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::load):

LayoutTests:

Unflag now passing media test on GTK and EFL.

* platform/efl/TestExpectations:
* platform/gtk/TestExpectations:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125045 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: generate preview for the objects dumped into the console upon logging.
https://bugs.webkit.org/show_bug.cgi?id=35801

Reviewed by Vsevolod Vlasov.

Source/WebCore:

As of today, dumping an object (array) into console will result in objects' properties being
read upon console object expansion (i.e. lazily). This means that dumping the same object while
mutating it will be hard to debug using the console.

This change starts generating abbreviated previews for objects / arrays at the moment of their
logging and passes this information along into the front-end. This only happens when the front-end
is already opened, it only works for console.log(), not live console interaction.

Covered by the existing console tests + collections test has been expanded to capture both: pre and post-
front-end opening scenarios.

* inspector/ConsoleMessage.cpp:
(WebCore::ConsoleMessage::addToFrontend):
* inspector/ConsoleMessage.h:
(ConsoleMessage):
* inspector/InjectedScript.cpp:
(WebCore::InjectedScript::wrapObject):
* inspector/InjectedScript.h:
(InjectedScript):
* inspector/InjectedScriptSource.js:
(.):
* inspector/Inspector.json:
* inspector/InspectorConsoleAgent.cpp:
(WebCore::InspectorConsoleAgent::enable):
(WebCore::InspectorConsoleAgent::addConsoleMessage):
* inspector/front-end/ConsoleMessage.js:
(WebInspector.ConsoleMessageImpl.prototype._format):
(WebInspector.ConsoleMessageImpl.prototype._formatParameter):
(WebInspector.ConsoleMessageImpl.prototype._formatParameterAsObject):
(WebInspector.ConsoleMessageImpl.prototype._formatParameterAsArrayOrObject):
(WebInspector.ConsoleMessageImpl.prototype._appendObjectPreview):
(WebInspector.ConsoleMessageImpl.prototype._formatParameterAsNode):
(WebInspector.ConsoleMessageImpl.prototype._formatParameterAsArray):
(WebInspector.ConsoleMessageImpl.prototype._printArray):
(WebInspector.ConsoleMessageImpl.prototype._formatAsArrayEntry):
(WebInspector.ConsoleMessageImpl.prototype._formatWithSubstitutionString):
* inspector/front-end/DOMExtension.js:
(Element.prototype.createTextChild):
* inspector/front-end/ObjectPropertiesSection.js:
(WebInspector.ObjectPropertiesSection):
* inspector/front-end/PropertiesSection.js:
* inspector/front-end/RemoteObject.js:
(WebInspector.RemoteObject):
(WebInspector.RemoteObject.fromPayload):
(WebInspector.RemoteObject.prototype.get previewProperties):
* inspector/front-end/Section.js:
* inspector/front-end/inspector.css:
(.console-group-messages .section .header .title):
(.section .console-formatted-node):
(.console-object-preview):
(.section .properties .name, .event-properties .name, .console-formatted-object .name):

LayoutTests:

* inspector/console/command-line-api-inspect-expected.txt:
* inspector/console/console-dir-expected.txt:
* inspector/console/console-eval-global-expected.txt:
* inspector/console/console-eval-global.html:
* inspector/console/console-format-collections-expected.txt:
* inspector/console/console-format-collections.html:
* inspector/console/console-format-expected.txt:
* inspector/console/console-format.html:
* inspector/console/console-log-document-proto-expected.txt:
* inspector/console/console-log-document-proto.html:
* inspector/console/console-log-toString-object-expected.txt:
* inspector/debugger/watch-expressions-panel-switch-expected.txt:
* inspector/elements/event-listener-sidebar-expected.txt:
* inspector/elements/event-listeners-about-blank-expected.txt:
* platform/chromium/inspector/console/console-dir-expected.txt:
* platform/chromium/inspector/console/console-eval-global-expected.txt: Removed.
* platform/chromium/inspector/console/console-format-collections-expected.txt:
* platform/chromium/inspector/console/console-format-expected.txt: Removed.
* platform/chromium/inspector/console/console-log-document-proto-expected.txt:
* platform/chromium/inspector/debugger/watch-expressions-panel-switch-expected.txt:
* platform/chromium/inspector/elements/event-listener-sidebar-expected.txt: Removed.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125046 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Until CSP fully supports paths, we should log a warning if we encounter a source with a path.
https://bugs.webkit.org/show_bug.cgi?id=93468

Patch by Mike West <mkwst@chromium.org> on 2012-08-08
Reviewed by Adam Barth.

Source/WebCore:

CSP 1.0 ignores path components of sources in directives' source lists.
'script-src http://example.com/path/to/directory' is treated exactly the
same as 'script-src http://example.com'. It's likely that this behavior
will change in CSP 1.1, which could break with developers' expectations.
This patch adds a warning when a path is encountered, alerting
developers to the fact that their current source is interpreted
differently than they might expect.

See http://crbug.com/128493 for additional context and discussion.

Tests for this change are covered by updating the existing Content
Security Policy tests to include the new console warnings.

* page/ContentSecurityPolicy.cpp:
(CSPSourceList):
(WebCore::CSPSourceList::CSPSourceList):
    Passing the directive name down into CSPSourceList so that we can
    generate informative error messages.
(WebCore::CSPSourceList::parse):
    Create a 'path' string, pass it into 'parseSource', and use it after
    parsing each source to determine whether a warning should be sent.
(WebCore::CSPSourceList::parseSource):
    Adding a 'path' argument so that we can see whether or not a
    specific source should generate a warning.
(WebCore::CSPDirective::CSPDirective):
    Passing the directive name down into CSPSourceList so that we can
    generate informative error messages.
(WebCore::ContentSecurityPolicy::reportIgnoredPathComponent):
    Generate the new warning message.
(WebCore):
* page/ContentSecurityPolicy.h:

LayoutTests:

* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowconnectionto.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowfontfrom.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowframefrom.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowimagefrom.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowmediafrom.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowobjectfrom.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowscriptfrom.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-allowstylefrom.html:
* http/tests/security/contentSecurityPolicy/1.1/securitypolicy-reporturi.html:
    All of the SecurityPolicy API tests with source lists contained
    sources with a trailing `/`. I've fixed that oversight.
* http/tests/security/contentSecurityPolicy/source-list-parsing-05-expected.txt:
* http/tests/security/contentSecurityPolicy/source-list-parsing-05.html:
* http/tests/security/contentSecurityPolicy/source-list-parsing-06-expected.txt:
* http/tests/security/contentSecurityPolicy/source-list-parsing-06.html:
    Updating the text of the test, and updating them to include the new
    console warnings.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@125047 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Make slider tick mark snapping threshold configurable for each platform
https://bugs.webkit.org/show_bug.cgi?id=93429

Reviewed by Kent Tamura.

Source/WebCore:

This makes the slider tick mark snapping threshold configurable for each platform.
And we increase the threshold for the Chromium port.

No new tests. Covered by range-snap-to-datalist.html.

* html/shadow/SliderThumbElement.cpp:
(WebCore::SliderThumbElement::setPositionFromPoint):
* rendering/RenderTheme.cpp:
(WebCore::RenderTheme::sliderTickSnappingThreshold):
(WebCore):
* rendering/RenderTheme.h:
(RenderTheme):
(WebCore::RenderTheme::sliderTickSnappingThreshold): Returns the threshold distance to the tick mark for snapping to occur.
* rendering/RenderThemeChromiumCommon.cpp:
(WebCore::RenderThemeChromiumCommon::sliderTickSnappingThreshold):
(WebCore):
* rendering/RenderThemeChromiumCommon.h:
(RenderThemeChromiumCommon):
* rendering/RenderThemeChromiumMac.h:
* rendering/RenderThemeChromiumMac.mm:
(WebCore):
(WebCore::RenderThemeChromiumMac::sliderTickSnappingThreshold):
* rendering/RenderThemeChromiumSkia.cpp:
(WebCore):
(WebCore::RenderThemeChromiumSkia::sliderTickSnappingThreshold):
* rendering/RenderThemeChromiumSkia.h:

LayoutTests:

* fast/forms/datalist/range-snap-to-datalist-expected.txt: Removed.
* fast/forms/datalist/range-snap-to-datalist.html: Changed so we can use this test for different snapping thresholds.
* platform/chromium/fast/forms/datalist/range-snap-to-datalist-expected.txt: Added.


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