Confirmed on Linux 2000080108. Changing OS/Plat to all.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Attempting to set document.attributes should *not* throw a NO_MODIFICATION_ALLOWED_ERR exception, NO_MODIFICATION_ALLOWED_ERR is a DOM exception defined to be thrown when a method is called or when a read-write property is set on a node in a circumstance where the property can not be set per the definitions in the DOM spec, e.g. document.nodeValue='foo'. Since the 'attributes' property is defined to be readonly in the DOM spec the behaviour of an attempt to set that readonly property in a language where that is even possible (it's not possible in C++ since the compiler would catch that as an error, i.e. there's no SetAttributes() method in the Node interface), is outside of the scope of the DOM spec. The DOM is language neutral but this issue is specific to JS. I do agree that mozilla should throw a JS exception when attempting to set a readonly property, but NO_MODIFICATION_ALLOWED_ERR is not the correct exception. Brendan, any ideas here, how can we get mozilla to throw an exception in this case?
Oops, forgot to CC! Brendan, please see my last comment.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Anyone who wants to fix this, an idea: readonly in DOM IDL maps to JSPROP_READONLY, which per ECMA-262, results in a property that can be assigned to without exception, but without effect. Suppose there were another keyword like readonly that connoted "throws exception" -- I can't think of a great name, so call it xreadonly. For that attribute, DOM idlc could generate a read/write JS property with a tinyid, whose setter throws the desired exception. /be
Mass update of qa contact
QA Contact: ckritzer → janc
QA contact Update
QA Contact: janc → desale
XPConnect now throws an exception if a readonly property is being set, marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
Severity: normal → critical
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
There is no spec that says what exception should be thrown when a property that is defined to be readonly in our IDL is being set in JS, the DOM spec has nothing to do with that, it's a language binding issue, not a DOM implementation issue. We throw a type error exception, and that's all we need to do. Marking FIXED again.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
this means as long as exception is thrown we are good
Status: RESOLVED → VERIFIED
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.