int is not a valid type in WebIDL. It should be long. We should replace int with long in bindings/scripts/test/*.idl. This is a follow-up patch for r123550.
Created attachment 154189 [details] Patch
Comment on attachment 154189 [details] Patch Attachment 154189 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13347052 New failing tests: http/tests/security/script-crossorigin-loads-correctly.html fast/loader/loadInProgress.html fast/inline/positionedLifetime.html fast/loader/unload-form-post-about-blank.html
Created attachment 154210 [details] Archive of layout-test-results from gce-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: gce-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
Comment on attachment 154189 [details] Patch Rejecting attachment 154189 [details] from commit-queue. New failing tests: http/tests/security/script-crossorigin-loads-correctly.html fast/loader/loadInProgress.html fast/inline/positionedLifetime.html fast/loader/unload-form-post-about-blank.html Full output: http://queues.webkit.org/results/13343058
Created attachment 154216 [details] Archive of layout-test-results from gce-cq-03 The attached test failures were seen while running run-webkit-tests on the commit-queue. Bot: gce-cq-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.39-gcg-201203291735-x86_64-with-Ubuntu-10.04-lucid
That makes no sense!
Yeah, let me cq+ it later again.
Created attachment 154302 [details] patch for landing
Comment on attachment 154302 [details] patch for landing Clearing flags on attachment: 154302 Committed r123600: <http://trac.webkit.org/changeset/123600>
(In reply to comment #0) > int is not a valid type in WebIDL. It should be long. We should replace int with long in bindings/scripts/test/*.idl. > > This is a follow-up patch for r123550. haraken, sorry if I am getting this wrong but does this mean we should not use int WebCore/*.idl files? like one is .../dom/Touch.idl: readonly attribute int webkitRadiusX;
(In reply to comment #10) > haraken, sorry if I am getting this wrong but does this mean we should not use int WebCore/*.idl files? > like one is > .../dom/Touch.idl: readonly attribute int webkitRadiusX; Per the spec, int is not allowed. But we need to care about compatibility when we replace the real IDL files. (Sorry I've not yet looked into them in detail.)
(In reply to comment #11) > (In reply to comment #10) > > haraken, sorry if I am getting this wrong but does this mean we should not use int WebCore/*.idl files? > > like one is > > .../dom/Touch.idl: readonly attribute int webkitRadiusX; > > Per the spec, int is not allowed. But we need to care about compatibility when we replace the real IDL files. (Sorry I've not yet looked into them in detail.) There shouldn't be any compat trouble since they're both JavaScript numbers.
(In reply to comment #12) > There shouldn't be any compat trouble since they're both JavaScript numbers. Thanks haraken/abarth for clarifying currently there are below listed idls with int attributes ./dom/Touch.idl: readonly attribute int webkitRadiusX; ./dom/Touch.idl: readonly attribute int webkitRadiusY; ./dom/WebKitNamedFlow.idl: readonly attribute int firstEmptyRegionIndex; ./html/canvas/WebGLActiveInfo.idl: readonly attribute int size; ./html/canvas/WebGLActiveInfo.idl: readonly attribute unsigned int type; ./html/canvas/WebGLShaderPrecisionFormat.idl: readonly attribute int rangeMin; ./html/canvas/WebGLShaderPrecisionFormat.idl: readonly attribute int rangeMax; ./html/canvas/WebGLShaderPrecisionFormat.idl: readonly attribute int precision; ./page/WebKitAnimation.idl: readonly attribute [Custom] int iterationCount; If its oke to replace these with long I can provide patch for all of them in one or separate patch. For ArrayBuffer.idl I have filed Bug92260 already.
I'd do them all together.