Closed Bug 591059 Opened 12 years ago Closed 9 years ago

ES5: Support read-only array lengths


(Core :: JavaScript Engine, defect)

Not set



Tracking Status
blocking2.0 --- .x+


(Reporter: jimb, Assigned: Waldo)



(Whiteboard: softblocker,[js:ni])

According to ES5, it should be possible to make an array's 'length' property read-only.  Various functions on Array.prototype will then fail in interesting ways, revealing implementation details, and many laughs may be had all around.

However, we don't implement this yet; search for uses of JSMSG_DEFINE_ARRAY_LENGTH_UNSUPPORTED.
Rob, do you think this should block?  It's pretty obscure.
blocks final.
blocking2.0: --- → final+
Frankly, I don't think we have time to do this along with everything else we still have to do in the way of ES5 stuff.

For another consideration, v8 doesn't implement it, and jsc probably doesn't either (the browser I have to test doesn't support it, although it's possibly just old).  I don't know what the latest IE preview does.  None of this means we shouldn't support it, of course, but it does counsel for a low priority in the immediate future.

But maybe I'm just mis-estimating how long this will take, and how long everything else we have to do will take, so we can run with it being a blocker for a bit.
blocking2.0: final+ → ---
OS: Linux → Windows CE
For what it's worth, this is a lot less work than a normal defineProperty: the only thing that can happen is that the length becomes read-only. We don't need to worry about enumerability, deletion, and all that mess.
This must be done. We can't ship without ES5 compliance. We can try to get you guys more help if needed.
blocking2.0: --- → ?
OS: Windows CE → All
Hardware: x86 → All
blocking2.0: ? → final+
Jeff, Jim, are you guys going to be ready to take this on, or do you need help?
I have my hands full with bug 514568 right now, and once that's done I'm currently looking at moving to compartments.  I probably don't have the time to touch this, unfortunately.
Assignee: general → bhackett1024
Can someone explain (here or IRC) why it is possible for the array length to be read only?  From the "ECMA-262 5th Edition / December 2009" PDF I got off the ECMAScript website (this is the right spec, right?):

--- Section (array lengths):

The length property of this Array object is a data property ...

The length property initially has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: false }.

--- Section 8.6.1 (attributes of data properties):

[[Configurable]] Boolean If false, attempts to delete the property, change the property to be an accessor property, or change its attributes (other than [[Value]]) will fail.

(note) [[Writable]] is another data property attribute.


The length property in an Array is by default a writable, non-configurable data property.  Since it's non-configurable it can't be made configurable, and since it's non-configurable it can't be made non-writable.
[[Configurable]] still permits changing the [[Writable]] field of data descriptors from true to false.  Try working through the steps for this code:

  Object.defineProperty([], "length", { writable: false });
(In reply to comment #9)
> [[Configurable]] still permits changing the [[Writable]] field of data
> descriptors from true to false.  Try working through the steps for this code:
>   Object.defineProperty([], "length", { writable: false });

OK, I see how that works now.  This does, however, flatly contradict 8.6.1.
Talked to brendan, going to disown this bug and work on other blockers and type inference.
Assignee: bhackett1024 → general
Whiteboard: softblocker
Any takers here? If not, I can take it, but I could use a little more information about what exactly we need to do here.
Brendan and I posted an awful hack in bug 598996 (more or less a dup of this one) which I think would fix this, or at least mostly fix it, with probably only spot-fixes to follow it.  But it is pretty awful, it may not be absolutely correct, it may fall over in ways you can't anticipate just from the spec (think DOM-internal property writes or something), and it may well be the wrong thing to do even for the short term.
Assignee: general → pbiggar
I think it's time (see bug 591846) to make our js::PropertyOp internal C-ish function getter and setter based properties act completely and consistently like the data properties that they report themselves as via Object.getOwnPropertyDescriptor, etc.

If we do that, then there should not be a special case needed here.

One concern is that our js::PropertyOp-flavored accessors may not have idempotent get/get and data-like set/get behavior. That could be but too bad: we should call the getter, check SameValue, and allow the writable to non-writable change permitted by ES5 for a non-configurable property.

I was done with hardblockers and warming up to look at bug 591846 again. More brains on what I am proposing here are good, but feel free to comment there.

(In reply to comment #14)
> If we do that, then there should not be a special case needed here.

OK, looks like you should take this one then. It was largely over my head anyway.
Assignee: pbiggar → brendan
Depends on: 591846
Depends on: 598996
No longer depends on: 591846
IE9rc supports read-only array lengths; if we pushed through on this (well, bug 598996) we could finish it up too.  Just a point to make before we pull the plug on this entirely for this release.

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage
blocking2.0: final+ → .x+
I hope this is easier now with shared-permanent dead. There may be some usable patch hunks over in bug 598996.

Assignee: brendan → jwalden+bmo
It apparently works to freeze an array as a whole, in which case the 'length' property appears to be non-configurable non-writable data property, as expected. However, even then, trying to defineProperty the length property to non-writable fails. Can this annoyance be fixed now? It is responsible for the only remaining "skip" entry in the SES whitelist (as of this writing)
> Object.defineProperty(Object.freeze([]), 'length', {writable: false})
InternalError: defining the length property on an array is not currently supported
We're fixing it, don't worry.  It's happening as part of a larger architectural change, tho, so it's a little slow in coming.
Blocks: 769872
Whiteboard: softblocker → softblocker,[js:ni]
Blocks: es-intl
No longer blocks: 769872
Blocks: 853702
Now that is fixed, does that in any way change the status of this bug?
Yeah, that bug basically *was* this one, but with less ancient noise to it -- making this a duplicate.
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 858381
You need to log in before you can comment on or make changes to this bug.