Open
Bug 633623
Opened 14 years ago
Updated 2 years ago
Decompilation using user-specified decompilation behavior changes observable error behavior
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
NEW
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.
|
||
Comment 1•14 years ago
|
||
Shorter and even more unfunny:
js> Object.prototype.toSource = {};
too much recursion
|
Assignee | |
Updated•10 years ago
|
Assignee: general → nobody
|
||
Comment 2•4 years ago
|
||
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.
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•