Document stackframe management and source selection in debugger codebase
Categories
(DevTools :: Debugger, enhancement)
Tracking
(firefox101 fixed)
Tracking | Status | |
---|---|---|
firefox101 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(3 files)
Stackframe management (fetch and map) is done in three distinct places differently without much inline comment.
Similarly, the various methods to select a source/location are missing some jsdoc as they behavior around generated/original source is non-trivial.
Assignee | ||
Comment 1•3 years ago
|
||
When selecting another thread/target, we shouldn't need to re-fetch frames/scopes.
This should always be done when paused() action is fired and data be stored and kept in the reducer.
But... this happen to be cancelled in middle of the processing when two thread pause concurrently.
This is experience by browser_dbg-windowless-workers.js.
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
I especially highlight the special behavior where the frontend tries
to keep selecting original source if we were already selecting an original source
and do the same when we were on a generated source.
Assignee | ||
Comment 3•3 years ago
|
||
When dispatching a JS Object, this won't be dispatching an async action.
Dropping the await will better highlight the synchronous dispatch calls.
Note that when we do
dispatch({
[PROMISE]: ...,
...
});
The promise middleware kicks in and the action becomes async.
So await is still relevant in front of these dispatches.
Comment 5•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d006a88ef4c2
https://hg.mozilla.org/mozilla-central/rev/7ee0b1be33d9
https://hg.mozilla.org/mozilla-central/rev/c95859201259
Description
•