Last Comment Bug 421433 - Error.prototype properties are JSPROP_ENUMERATE
: Error.prototype properties are JSPROP_ENUMERATE
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla1.9beta5
Assigned To: general
: Jason Orendorff [:jorendorff]
javascript:s='';for(i in Error.protot...
Depends on:
  Show dependency treegraph
Reported: 2008-03-06 17:59 PST by Brendan Eich [:brendan]
Modified: 2011-08-04 08:23 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

don't enum these props on the prototype (780 bytes, patch)
2008-03-10 14:26 PDT, Brian Crowder
brendan: review-
Details | Diff | Splinter Review

Description User image Brendan Eich [:brendan] 2008-03-06 17:59:13 PST
Contrary to ECMA-262 Edition 3, section 15 intro and 15.11.4.

Easy fix, good for ACID3? Dunno, but trivially safe. Brian, can you do the deed?

Comment 1 User image Brian Crowder 2008-03-10 14:26:32 PDT
Created attachment 308484 [details] [diff] [review]
don't enum these props on the prototype
Comment 2 User image Brendan Eich [:brendan] 2008-03-11 22:04:43 PDT
Comment on attachment 308484 [details] [diff] [review]
don't enum these props on the prototype

Seems not to hit exn_resolve, need that too.

diff -pu8 is best, old style is strangely nostalgic, tho ;-).

Comment 3 User image Brian Crowder 2008-04-25 11:51:14 PDT
I don't think we do want to remove the JSPROP_ENUMERATE setting from exn_resolve, since we do want non-prototype properties to be enumerable, don't we?  Should I be special-casing in exn_resolve for the prototype?
Comment 4 User image Brendan Eich [:brendan] 2008-04-25 15:13:33 PDT
Good question -- it's an efficiency bug that exn_resolve does not cast out JSRESOLVE_ASSIGNING with an early return. It is trying to bind instance props such as message, fileName, lineNumber on demand, even though the class init code bothered to put default-valued props of the same names (not stack, though) on the *Error.prototype objects.

The reason it's doing this is to reflect the native JSExnPrivate member back into JS, and it can't do this via prototype getters without making a new string (for the string-valued props) on each get.

But the effect is to make a property in each instance, on demand. ES3 says there are no per-instance props, though:

15.11.5 Properties of Error Instances
Error instances have no special properties beyond those inherited from the Error prototype object.

I think the spec is kind of broken here, but no matter. It allows additional properties.

But this brings us back to the current bug. That we shadow the uselessly-default-valued proto-props (save for stack, which is always per-instance, not in any prototype) in order to avoid making extra strings, should not change the enumerability per ES3 of at least the 'message' prop.

So I'd still think non-enumerable properties are right for the per-instance ones too.

Comment 5 User image Brian Crowder 2009-03-30 15:51:38 PDT
This is a spec bug that probably needs more love than I can give.

Note You need to log in before you can comment on or make changes to this bug.