Open Bug 1381965 Opened 7 years ago Updated 2 years ago

Implement toString for NonSyntacticVariablesObjects

Categories

(Core :: JavaScript Engine, enhancement, P3)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: mccr8, Assigned: tcampbell)

References

Details

Bug 1186409 exposes these to chrome JS, and it is kind of crummy for debugging if you just get an error if you try to print it. This would just do whatever we do for the global, except adjusted for the NSVO.
JS_STRING_SYM_PS seems to maybe do what we'd need.
Blocks: 1381961
Is this something we still need to do, Ted? I guess the NSVO is still exposed to JS as |this|, right?
Flags: needinfo?(tcampbell)
Yeah, we should. I'll take a look at it tomorrow.
Assignee: nobody → tcampbell
Status: NEW → ASSIGNED
Flags: needinfo?(tcampbell)
Priority: -- → P2
The issue is that in XPCShell, we use ToString in the REPL. The current NSVO has a null __proto__ and therefore has neither a |@@toPrimitive| or |toString| methods.

In the jsshell we use JS_ValueToSource which gives us a reasonable result there. For a BackstagePass in xpcshell, the global uses XPC_WN_Shared_toPrimitive since it is an XPC object. The devtools browser console is able to give it's own reasonable rendering of the NSVO.

We can either set a |@@toPrimitive| method on the NSVO, or give the NSVO a more reasonable prototype. Either way, I believe the fix will live in XPConnect since it is what decides what the global prototype chain looks like.

We should figure out which value of this.__proto__ is least surprising:
 - null
 - this.__proto__ == Cu.getGlobalForObject(this).__proto__
 - ???
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
See Also: → 1780504
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.