288321 - setting a readonly attribute from javascript doesn't always throw an error

Status: RESOLVED INVALID

(Core :: XPConnect, defect)

Description

[Michiel van Leeuwen (email: mvl+moz@)]

When tryin to find out what the problem was in bug 287985 comment 3, i found out
that setting a readonly property from javascript didn't throw an error.

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: testcase

attaching testcase to use in xpcshell.
I noticed that trying to set .creationTime does throw an error, but .entryDate
doesn't. This last attribute might be made readwrite to fix 287985, so you
might need to back out any patches for that bug.

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

in comment 0, i mean attribute, not property...

Comment 3

[David Bradley]

I remember running into this long ago, and brendan having an explanation.

Comment 4

[Brendan Eich [:brendan]]

An explanation for what?  ECMA-262 says setting a read-only property silently
fails to update the property's value (but the result of the assignment
expression is the right-hand side).  I don't like that, but it got past me
(there was some pseudo-vote, or horse-trading; I forget which) in the ECMA-262
Edition one days back in 1997.

Why some XPIDL-induced properties can't be set without an exception being thrown
is another question.  Was that the issue here?  If the ECMA-262 spec is the only
issue, this bug is INVALID.

/be

Comment 5

[David Bradley]

It was the ECMA spec sitation that I couldn't remember.

Looking at mvl's comment in the other bug, the issue is an interface with read-
only properties.

In the view of trying to mimic JS behavior on native objects this silently 
fails in XPConnect as well. It would be easy enough to have this throw an 
exception. I wonder how many things would complain if this now became the 
behavior? Hopefully no one would have intentionally taken advantage of this.

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

Whatever the correct behaviour is, it should be consistent. As it is now,
setting one attribute throws an error, while another doesn't. (see comment 1)

Comment 7

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Not throwing is the correct behaviour per WebIDL. -> INVALID?