Introduce a test to cover an original source being removed and replaced in the bundle/generated source by a new original source
Categories
(DevTools :: Debugger, task)
Tracking
(firefox99 fixed)
| Tracking | Status | |
|---|---|---|
| firefox99 | --- | fixed |
People
(Reporter: ochameau, Assigned: ochameau)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
This usecase isn't covered by any test while this might be a common thing happening when using webpack.
The actual behavior of the debugger is quite unknown.
Thanks to this test, we can see that breakpoints set on the removed original file are still hit if the bundle sources are still run. The UI will update the breakpoint as if it was set against the new original source.
|
Assignee | |
Comment 1•3 years ago
|
||
I'm using a new dedicated bundle here so that we ensure that the bundle lines don't change and stay "breakable".
Otherwise the breakpoint wouldn't be hit on reload if the breakpoint become an empty line.
My goal here is to see what happens if the new bundle still hit the breakpoint even if the original source
was removed.
We might later revisit this behavior to remove this breakpoint.
It might be challenging to avoid hitting the breakpoint once on the first load.
It would require the server to know about sourcemap in order to ignore the breakpoint on early page load sequence.
|
||
Updated•3 years ago
|
|
|
Assignee | |
Comment 2•3 years ago
|
||
This helps stop doing a loose search and avoid bugs where
findSource("original.js") would match both original.js and replace-original.js.
|
|
Assignee | |
Comment 3•3 years ago
|
||
|
|
Assignee | |
Comment 5•3 years ago
|
||
|
||
Comment 7•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/bf3f87846256
https://hg.mozilla.org/mozilla-central/rev/bb31441f4fc4
https://hg.mozilla.org/mozilla-central/rev/c8ac9e04a62f
https://hg.mozilla.org/mozilla-central/rev/42920d1d4aff
Description
•