497110 - Need a way to cause auto-type-conversions on array element set

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Currently, canvas imagedata uses a JS array for its actual data.  This has the benefit that sets and gets from JS are fast, but the drawback that someone can stick an entirely new object into the imagedata as the actual data, and can stick all sorts of arbitrary stuff into the array.

Ideally, we'd implement the HTML5 spec on this, which as I understand it prevents assigning a random object to imagedata.data and does automatic conversion to an unsigned int in the 0-255 range on property set on the data.  If we did this, we could get rid of the slow path in nsCanvasRenderingContext2D::PutImageData, since the imageData would always contain the right thing.

A possible option here, of course, is to stop using a JS array altogether and use an XPConnectified object with classinfo, but I think that ends up with much higher get/set overhead.

Comment 1

[Brendan Eich [:brendan]]

Set URL to spec link? What happens when an array element is the string "foozle"? Conversion to NaN, then to 0? Or throw?

/be

Comment 2

[Boris Zbarsky [:bzbarsky]]

> Set URL to spec link?

Sure thing.  See url field.

Summary:

  JS undefined values must be converted to zero. Other values must first be
  converted to numbers using JavaScript's ToNumber algorithm, and if the
  result is a NaN value, then the value must be converted to zero. If the
  result is less than 0, it must be clamped to zero. If the result is more
  than 255, it must be clamped to 255. If the number is not an integer, it
  should be rounded to the nearest integer using the IEEE 754r
  convertToIntegerTiesToEven rounding mode

Comment 3

[Brendan Eich [:brendan]]

To make sure I understand: we are using a JS Array as our implementation of the WebIDL CanvasPixelArray interface type?

/be

Comment 4

[Boris Zbarsky [:bzbarsky]]

That is correct.  And a JSObject with three properties as our implementation of the ImageData type.  We could change that without too much trouble, though, since performance there is not an issue.

Comment 5

[Tom S. (please needinfo tschuster)]

We use typed arrays for this now.