756203 - setters are not called on Float32Array

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Erich Ocean]

When using Object.defineProperty() on Float32Array.prototype, getters are called, but setters are not. This does not match the behavior of v8, JavaScriptCore, or Internet Explorer.

If you do Float32Array.prototype.__lookupSetter__, you can retrieve the setter and then call it, and the result is correct.

I have attached an HTML file demonstrating the issue.

Comment 1

[Erich Ocean]

Attachment: HTML file demonstrating the issue.

Comment 2

[Steve Fink [:sfink] [:s:]]

This appears to be intentional, and comes from this code in obj_setGeneric in js/src/jstypedarray.cpp:

        // We can't just chain to js_SetPropertyHelper, because we're not a normal object.
        if (!isArrayIndex(cx, tarray, id, &index)) {
            // Silent ignore is better than an exception here, because
            // at some point we may want to support other properties on
            // these objects.  This is especially true when these arrays
            // are used to implement HTML Canvas 2D's PixelArray objects,
            // which used to be plain old arrays.
            vp->setUndefined();
            return true;
        }

Apparently, the spec is ambiguous on this point. But at the very least, it seems odd for getters to work but setters to be ignored.

Comment 3

[Erich Ocean]

Okay, so I get that you don't support adding properties. My code, however, doesn't add new properties, so it would be safe to call. Perhaps setters should be allowed, and the above if () amended to only disallow actual, honest-to-goodness property setting, not merely calling a setter itself.

Presumably, that wouldn't break anything else in the runtime, and would at least be an improvement over what is there now pending a fuller implementation.

Comment 4

[Erich Ocean]

Expanding on my comment, basically we could do whatever it is __lookupSetter__ is doing now, and if we get a result, call it. Otherwise, the existing behavior stands.

Comment 5

[Mike Stay]

Please add the ES5 tag to this bug.  Host objects can do whatever they want with respect to setters, but it would be in the spirit of ES5 strict to throw rather than failing silently.

Comment 6

[Mike Stay]

That is, it would be nice if it threw while in strict mode.

Comment 7

[asko.soukka]

Any new thoughts on this? It's unfortunate that Firefox behaves differently from the others :/

Comment 8

[Geoffrey D]

I too am trying todo something similar to Erich, by having aliases to positions in the array. 

Having consistant behaviour here would be wonderful.

Comment 9

[Jeff Walden [:Waldo]]

This will be fixed in the process of fixing bug 586842, which has been, and continues to be, a long slog.  I keep getting tripped up on other things that need to be fixed in the way of that, but I expect it to happen sometime this fall.

Comment 10

[André Bargull [:anba]]

No longer reproducible - resolving as WFM.