Obsolete
Status Update
Comments
dg...@chromium.org <dg...@chromium.org> #2
[Empty comment from Monorail migration]
vs...@chromium.org <vs...@chromium.org> #3
Assigning to aandrey@ for further triage.
aa...@chromium.org <aa...@chromium.org> #4
Yang, what do you think about this?
ya...@chromium.org <ya...@chromium.org> #5
Basically that would mean that we would have a break point, where, upon breaking, would set the return target to a different PC, depending on statement position of where the break point was dropped.
I foresee a couple of issues:
- The expected stack at the target position may be different than the original position. In the full codegen, we have no way to track the diff across different statement positions. With the wrong stack layout we would probably get a crash.
- Same goes for register content.
- The original break position might be at an IC, the new one at a break slot (or vice versa).
- What do we do if the break point is moved up in a loop?
It just seems to me that the effort to accomplish this is disproportionate to what we would gain. It would also make the debugger even more complex.
I foresee a couple of issues:
- The expected stack at the target position may be different than the original position. In the full codegen, we have no way to track the diff across different statement positions. With the wrong stack layout we would probably get a crash.
- Same goes for register content.
- The original break position might be at an IC, the new one at a break slot (or vice versa).
- What do we do if the break point is moved up in a loop?
It just seems to me that the effort to accomplish this is disproportionate to what we would gain. It would also make the debugger even more complex.
pa...@chromium.org <pa...@chromium.org> #6
[Empty comment from Monorail migration]
pa...@chromium.org <pa...@chromium.org> #7
We're going to hold off on this feature for now.
It's complexity is high and it's not common enough a workflow.
One could also just comment out the lines and hit ctrl-s to get the same effect, pretty much.
It's complexity is high and it's not common enough a workflow.
One could also just comment out the lines and hit ctrl-s to get the same effect, pretty much.
[Deleted User] <[Deleted User]> #8
The trick of commenting out a line and saving would be more helpful IF you could do that to in-line scripts in the main page. As far as I can see, you can only edit lines in downloaded .js files, not in embedded <script> tags.
BTW, this is NOT an unusual thing to do at all - the need for this comes up all the time.
BTW, this is NOT an unusual thing to do at all - the need for this comes up all the time.
ya...@chromium.org <ya...@chromium.org> #9
This is non-trivial. V8 simply does not compile code in a way that allows for skipping code. There are a ton of situations where it's not obvious what the expectation should be.
[Deleted User] <[Deleted User]> #10
@yangguo, I didn't say it was a trivial feature - I'm pointing out this is a really important, useful feature. Some of the above comments seemed to minimalize the usefulness of the feature...just wanted to point out this isn't a universal opinion. :)
As for 'what the expectation is, look at how Visual Studio handles setting the next instruction to execute. MS actually has this part dialed in and they do a good job on this.
Cheers
As for 'what the expectation is, look at how Visual Studio handles setting the next instruction to execute. MS actually has this part dialed in and they do a good job on this.
Cheers
ma...@gmail.com <ma...@gmail.com> #11
I will second Paul, this is something that everyone who works with js runs into daily... just look at amount of attention this question on SO has generated... https://stackoverflow.com/questions/24138455/skip-line-while-debugging-in-chrome-developer-tools/30324344#30324344 Hope this will help to reconsider...
an...@asteitz.com <an...@asteitz.com> #12
I will second/third Paul. Not doubting that this is non-trivial. However, as Paul pointed out the "comment code and save it" option only works in .js files not in script embedded in the html. Making it work for script embedded in html would be a nice help. Not sure if that is also non-trivial.
ma...@gmail.com <ma...@gmail.com> #13
Also since when only 'trivial' solutions are being accepted, you might want to get someone who can do better than [], lol.
ma...@gmail.com <ma...@gmail.com> #14
[Comment Deleted]
ma...@gmail.com <ma...@gmail.com> #15
Editing the script in live mode also doesn't work for pretty-printed/formatted script files. See https://bugs.chromium.org/p/chromium/issues/detail?id=341848 .
ma...@gmail.com <ma...@gmail.com> #16
This question on SO has ~20k views, which would imply that there should be no less than 20 thousand users that were looking for this feature and didn't get it. Also aandrey@chromium.org hasn't looked at the issue for 900+ days. Maybe it would be time to have a look at it again with different dev?
le...@gmail.com <le...@gmail.com> #17
I'd agree this functionality isn't really needed if you could always/reliably edit the code that was being executed, but if it's code on the main page itself, this doesn't seem to work, even if you edit it via the Elements/DOM view (via the Source view it won't let you edit it at all, regardless of whether pretty print is on).
le...@gmail.com <le...@gmail.com> #18
(btw in my case I didn't even need to edit the code while stepping through - I just wanted to comment out a line of code in the javascript that was causing the page to reload, which was making debugging almost impossible!)
je...@gmail.com <je...@gmail.com> #19
So, I take this isn't ever going to happen? Hell, I'm going back to IE, lol.
bm...@chromium.org <bm...@chromium.org> #20
I'm not sure what this feature request is about exactly:
1. Is it about dragging and dropping breakpoints to a different location?
2. Or is it about adjusting the instruction pointer (like Visual Studio debugger can do)?
In case of 1. it might make sense to reconsider, for 2. it's very unlikely that we will ever be able to do that with Chrome DevTools (beyond the existing "Restart Frame" feature).
1. Is it about dragging and dropping breakpoints to a different location?
2. Or is it about adjusting the instruction pointer (like Visual Studio debugger can do)?
In case of 1. it might make sense to reconsider, for 2. it's very unlikely that we will ever be able to do that with Chrome DevTools (beyond the existing "Restart Frame" feature).
ra...@gmail.com <ra...@gmail.com> #21
It is about #2, the ability to manually skip lines of code during live debugging.
bm...@chromium.org <bm...@chromium.org> #22
Ok, that is definitely out of scope currently. Given the complexity of JavaScript execution in V8, it's also unlikely that this will ever be implemented.
is...@google.com <is...@google.com> #23
This issue was migrated from crbug.com/chromium/382904?no_tracker_redirect=1
[Auto-CCs applied]
[Multiple monorail components: Platform>DevTools, Platform>DevTools>JavaScript]
[Monorail components added to Component Tags custom field.]
[Auto-CCs applied]
[Multiple monorail components: Platform>DevTools, Platform>DevTools>JavaScript]
[Monorail components added to Component Tags custom field.]
ch...@gmail.com <ch...@gmail.com> #24
"
Why is this marked as obsolete?
Description
Steps to reproduce the problem:
1. Place breakpoint on line of javacript code
2. Run code so that breakpoint is hit
3. Drap and Drop breakpoint few lines down in such a way that lines that are skipped would not be executed.
What is the expected behavior?
Skip the execution of lines
What went wrong?
There is not such feature that would allow drag and drop breakpoints.
Did this work before? No
Chrome version: 35.0.1916.114 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 13.0 r0
originated from