This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The CSSOM View spec is unclear on how implementations should react when a client attempts to set a value for an immutable property. Examples include any of the properties of the Screen interface in section 4.2. The following code should throw an exception, but instead fails silently: window.screen.height = 0; This behavior should be specified in the document.
(In reply to comment #0) > The CSSOM View spec is unclear on how implementations should react when a > client attempts to set a value for an immutable property. Examples include any > of the properties of the Screen interface in section 4.2. These sort of information is encoded in the WebIDL fragment. In this case, it is # readonly attribute unsigned long height; and WebIDL interprets "readonly"[1] as # The attribute setter is undefined if the attribute is declared readonly # and has neither a [PutForwards] nor a [Replaceable] extended attribute # declared on it. and the attribute setter, when undefined, fails silently: [[ << var o = {get x(){return 1;}} >> undefined << o.x >> 1 << o.x = 0 >> 0 << o.x >> 1 ]] > The following code should throw an exception, but instead fails silently: > > window.screen.height = 0; If this is your main request, I would suggest you change the title as such (ideally, send this along with why you think so to www-style to attract broader discussions, since "readonly" is as far as I can tell a common pattern in various interfaces so you might want to provide stronger rationale.) Also, you might want to provide information about current implementations. (Do some of them throw instead of fail silently?) > This behavior should be specified in the document. I do from time to time think these "keywords" in WebIDL fragments should be linked to corresponding WebIDL parts... [1] http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute-setter
reassign to myself; apparently i am not the default assignee for this component
This is defined in WebIDL.
(In reply to comment #3) > This is defined in WebIDL. Only partly... the key language in WebIDL is [1]: "The attribute setter is undefined if the attribute is declared readonly and has neither a [PutForwards] nor a [Replaceable] extended attribute declared on it." [1] http://www.w3.org/TR/WebIDL/#es-attributes in combination with EMCA-262 5.1 definitions of [[Writable]] (8.6.1), [[CanPut]] (8.12.4), PutValue(V,W) (8.7.2), and definition of strict mode (see appendix C for a summary). "The LeftHandSide also may not be a reference to a data property with the attribute value {[[Writable]]:false}, to an accessor property with the attribute value {[[Set]]:undefined}, nor to a non-existent property of an object whose [[Extensible]] internal property has the value false. In these cases a TypeError exception is thrown (11.13.1)." See also the note in [1]: "Note that attempting to assign to a property corresponding to a read only attribute results in different behavior depending on whether the script doing so is in strict mode. When in strict mode, such an assignment will result in a TypeError being thrown. When not in strict mode, the assignment attempt will be ignored."
Yes? "undefined" there is the JS value undefined, not that it's not defined in the spec. That the behavior differs between strict and non-strict similarly doesn't mean it's not defined in the spec.
(In reply to comment #5) > Yes? "undefined" there is the JS value undefined, not that it's not defined > in the spec. That the behavior differs between strict and non-strict > similarly doesn't mean it's not defined in the spec. I was just providing further background about whether throwing TypeError causes an exception or not when attempting to write a readonly data property. In particular, the JS must be running in strict mode to see this exception.