'length' property of DOM bindings functions returns wrong value
https://bugs.webkit.org/show_bug.cgi?id=110569

Reviewed by Geoffrey Garen.

Source/WebCore:

Make the 'length' property of Function objects and Interface
objects behave according to the latest Web IDL specification
editor draft:
http://dev.w3.org/2006/webapi/WebIDL/#es-interface-call
http://dev.w3.org/2006/webapi/WebIDL/#es-operations

As a result, only mandatory arguments are taken into account
when computing the value for the 'length' property. This
behavior is consistent with Firefox and Blink.

Tests: fast/js/constructor-length.html
       fast/js/function-length.html

* bindings/scripts/CodeGeneratorJS.pm:
(GenerateImplementation):
(GenerateConstructorHelperMethods):
Update the JSC code generator to only account for mandatory parameters
when computing the value for the 'length' property of Function objects
and constructors.

* bindings/scripts/test/JS/JSTestActiveDOMObject.cpp:
(WebCore::JSTestActiveDOMObjectConstructor::finishCreation):
* bindings/scripts/test/JS/JSTestCustomNamedGetter.cpp:
(WebCore::JSTestCustomNamedGetterConstructor::finishCreation):
* bindings/scripts/test/JS/JSTestEventConstructor.cpp:
(WebCore::JSTestEventConstructorConstructor::finishCreation):
* bindings/scripts/test/JS/JSTestEventTarget.cpp:
(WebCore::JSTestEventTargetConstructor::finishCreation):
(WebCore):
* bindings/scripts/test/JS/JSTestException.cpp:
(WebCore::JSTestExceptionConstructor::finishCreation):
* bindings/scripts/test/JS/JSTestInterface.cpp:
(WebCore::JSTestInterfaceConstructor::finishCreation):
* bindings/scripts/test/JS/JSTestMediaQueryListListener.cpp:
(WebCore::JSTestMediaQueryListListenerConstructor::finishCreation):
* bindings/scripts/test/JS/JSTestNamedConstructor.cpp:
(WebCore::JSTestNamedConstructorConstructor::finishCreation):
(WebCore::JSTestNamedConstructorNamedConstructor::finishCreation):
* bindings/scripts/test/JS/JSTestObj.cpp:
(WebCore):
* bindings/scripts/test/JS/JSTestSerializedScriptValueInterface.cpp:
(WebCore::JSTestSerializedScriptValueInterfaceConstructor::finishCreation):
(WebCore):
* bindings/scripts/test/JS/JSTestTypedefs.cpp:
(WebCore):
Rebaseline bindings tests results.

* fileapi/Blob.idl:
Remove 'ConstructorParameters=2' extended attribute as the correct value
is 0, given that a Blob can be constructed without parameter.

* html/canvas/DataView.idl:
Update ConstructorParameters extended attribute value from 3 to 1 as only
one of the 3 parameters is mandatory.

* html/canvas/Float32Array.idl:
* html/canvas/Float64Array.idl:
* html/canvas/Int16Array.idl:
* html/canvas/Int32Array.idl:
* html/canvas/Int8Array.idl:
* html/canvas/Uint16Array.idl:
* html/canvas/Uint32Array.idl:
* html/canvas/Uint8Array.idl:
* html/canvas/Uint8ClampedArray.idl:
Remove 'ConstructorParameters=1' extended attribute from interfaces using
'ConstructorTemplate=TypedArray' as the bindings generator now properly
compute the number of constructor parameters for such interfaces.

* page/WebKitPoint.idl:
Remove 'ConstructorParameters=2' extended attribute as the correct value
should be 0, given that a WebKitPoint can be constructed without parameters.

LayoutTests:

Update fast/js/constructor-length.html test case now that only
mandatory arguments are considered for the constructor length.

Also add a new fast/js/function-length.html test to make sure
that the 'length' property of Function objects from DOM
bindings behaves according to the Web IDL specification as
this was not covered by existing tests.

* fast/files/blob-constructor-expected.txt: Rebaseline.
* fast/files/script-tests/blob-constructor.js: Update test now that Blob constructor
length is 0 instead of 2.
* fast/js/constructor-length.html:
* fast/js/function-length-expected.txt: Added.
* fast/js/function-length.html: Added.
* platform/blackberry/fast/js/constructor-length-expected.txt: Rebaseline.
* platform/efl/TestExpectations: Unskip fast/js/constructor-length.html for EFL port.
* platform/efl/fast/js/constructor-length-expected.txt: Copied from LayoutTests/platform/mac/fast/js/constructor-length-expected.txt.
* platform/gtk/fast/js/constructor-length-expected.txt: Rebaseline.
* platform/mac/fast/js/constructor-length-expected.txt: Rebaseline.
* platform/qt/fast/js/constructor-length-expected.txt: Rebaseline.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@148997 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Don't create compositing layers for sticky position unless using the ScrollingCoordinator
https://bugs.webkit.org/show_bug.cgi?id=115060

Source/WebCore:

Reviewed by Tim Horton.

Creating compositing layers for sticky position elements is only useful
when we're using a ScrollingCoordinator, so don't create them if
we're not in a frame that uses a scrolling coordinator.

Tests: compositing/layer-creation/no-compositing-for-sticky.html
       platform/mac-wk2/tiled-drawing/sticky/sticky-layers.html

* rendering/RenderLayerCompositor.cpp:
(WebCore::RenderLayerCompositor::requiresCompositingForPosition):

LayoutTests:

Reviewed by Tim Horton.

Tests that we create layers for sticky position when in tiled drawing mode,
and that we have no layers when not.

* compositing/layer-creation/no-compositing-for-sticky-expected.txt: Added.
* compositing/layer-creation/no-compositing-for-sticky.html: Added.
* platform/mac-wk2/tiled-drawing/sticky/sticky-layers-expected.txt: Added.
* platform/mac-wk2/tiled-drawing/sticky/sticky-layers.html: Added.

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