Open Bug 633623 Opened 11 years ago Updated 1 year ago

Decompilation using user-specified decompilation behavior changes observable error behavior

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

People

(Reporter: Waldo, Unassigned)

References

(Blocks 1 open bug)

Details

var toSource = function() { throw 17; }
  Object.preventExtensions(this);
  eval("var x");

According to ES5 this should throw a TypeError, but because we invoke the user-specified toSource function when decompiling the global object, we instead end up throwing 17.  We should not invoke the user-specified method here and should instead use only our own decompilation facilities.
Shorter and even more unfunny:

  js> Object.prototype.toSource = {};
  too much recursion
Assignee: general → nobody
Depends on: 1055307
Blocks: 1183241

I am vaguely optimistic that we could do this nowadays. The Firefox devtools now use their own code for displaying error objects, so they don't depend on toStringResult as much anymore. This could however regress the error message we log to stdout (and maybe the Browser console), so this could be annoying for Firefox/Gecko developers.

Oh additionally we are pretty far with removing toSource in general. They are not defined on content JS accessible objects anymore. js::ValueToSource will still try to invoke toSource even with toSourceEnabled is false. We should fix that. Additionally some of the other custom formatters like ArrayToSource are not side-effect free either.

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