[Bug 29004] FrozenArray only provides shallow immutability

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29004

--- Comment #7 from Boris Zbarsky <bzbarsky@mit.edu> ---
It's really hard to accidentally delete Document.prototype.getElementById. 
It's easy to accidentally foo.bar.sort() or pass foo.bar to some library
function that modifies it.  Again, the frozenness is meant to prevent
accidental modification, not attacks.  And it's just a lot easier to
accidentally modify an array you're working with in JS than it is to
accidentally modify a random DOM prototype.  That's the whole point of this
discussion, and I think arguing that scripts rarely do the latter (though some
do, and stuff breaks, in fact) doesn't shed much light on how likely scripts
are to do the former.

> These would be the kind of mutations that one author script could do that would
> damage/inhibit other author script from having a good experience. 

Sure.

> (Similar to my delete example above.)

I think it's a lot more common to process an array via a while-loop-with-pop
than it is to delete things off standard prototypes, for what it's worth.

> However, the following are OK, and do not throw:
>```navigator.plugins["100"] = { travis: "test" };```

This throws in strict mode per webidl spec and in at least Firefox.  In
non-strict mode it's a silent no-op.  The same is true for a frozen array, of
course.

>```navigator.plugins.test = "value";```

Note that this would also not throw outside strict mode with a frozen array. 
But neither would it work, of course.

So maybe instead of freezing the array, we could mark all the properties
0-length and "length" itself readonly noncofigurable, but allow adding other
random properties...  It's a lot more complicated than just freezing, but is
the minimal thing with the desired behavior.

> My argument is that we should be not be swinging toward more restrictive,
> rather we should be swinging toward less restrictive and more flexible.

I understand that argument, and maybe we should try to find some middle ground
between just letting anyone stomp on the array accidentally via sort() and
locking it down completely.

> Furthermore, if the issue is a desire to convert existing array-like things

To some extent, but chances are that's not very web-compatible because of
differences in concat() behavior, so this is mostly about new things, I
think...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 31 July 2015 19:32:28 UTC