Devtool do not show function name for dynamic named function in call stack
Categories
(DevTools :: Debugger, defect, P3)
Tracking
(Not tracked)
People
(Reporter: mmis1000, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
- Create a function with dynamic generated Function::name
{
function withName(name, cb, ...args) {
var obj = {
[name]: function () {
return cb.apply(this, arguments)
}
}
return obj[name]
}
const name = `南無喝囉怛那哆囉夜耶`
const makeError = () => { debugger; throw new Error() }
let decorated = makeError
withName(name, makeError)()
}
- invoke it and see the both call stack in
devtool
andError::stack
Actual results:
They both show the function named as we supplied 南無喝囉怛那哆囉夜耶
Expected results:
The devtool shows it as withName
(wrong)
The Error::stack
shows as we expect. (correct)
The devtool shows it as withName (wrong)
https://i.imgur.com/qiUyZc5.png
The Error::stack shows as we expect. (correct)
https://i.imgur.com/O2h6unN.png
Images
Oops.. I write the Actual results: ans the Expected results: in wrong section.
Someone help?
Comment 3•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 4•4 years ago
|
||
The severity field is not set for this bug.
:jlast, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 5•4 years ago
|
||
This is a debugger frontend issue. We get the right name from the server, but our code in https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/devtools/client/debugger/src/actions/pause/mapDisplayNames.js#31 is then overriding the good name from the server with a worse name.
This logic exists to give better names to things in the context of sourcemaps, but it's clearly too aggressive here. It looks like it uses "closest", so that is probably what we need to change. We should only use the original function name if the location is an exact match. I assume the "closest" ends up being the parent function, hence the strange behavior here.
Description
•