Avoiding disappearing breakpoints in script files

[mobi...@gmail.com]

Hi all,

I've been experiencing a problem with the script tag lately. I must be accidentally changing the scripts while I'm debugging as the script filename in its tab shows an asterisk. When this happens, all breakpoints for that file immediately disappear. 

It's a real pain, because sometimes you can have a bunch of breakpoints set, then you type a key without realizing that cursor is active in the script view, the file is changed and you lose all your breakpoints. I was at a dev conference in San Francisco earlier this week and talked to many JS devs that are wits end with this "feature".

Is there any way to avoid this? Can you disable editing of the script files? Is there any way to revert the files if you accidentally change them and get your breakpoints back? Any suggestions would help. I've used Chrome Dev Tools for ages and have never seen this issue before. 

Thanks,
JC

[Abraham Williams]

In my experience even editing the the JS file server side doesn't drop the breakpoints so it sounds like a bug. Check to see if there is an open bug report and if not please create a new on. http://new.crbug.com

Abraham
--
Abraham Williams | abrah.am | abraham+

@abraham | github.com/abraham | blog.abrah.am
This email is: [ ] shareable [x] ask first [ ] private.

[John J Barton]

On Wed, May 23, 2012 at 2:54 PM, <mobi...@gmail.com> wrote:

> Hi all,
>
> I've been experiencing a problem with the script tag lately. I must be
> accidentally changing the scripts while I'm debugging as the script filename
> in its tab shows an asterisk. When this happens, all breakpoints for that
> file immediately disappear.

It would be helpful if you can give very specific steps to reproduce
your experience.

My guess: you are clicking on the script source area in order to raise
the window?

>
> It's a real pain, because sometimes you can have a bunch of breakpoints set,
> then you type a key without realizing that cursor is active in the script
> view, the file is changed and you lose all your breakpoints. I was at a dev
> conference in San Francisco earlier this week and talked to many JS devs
> that are wits end with this "feature".

Just to give a voice to the other side, I've switched to using
devtools for editing .js files. Still some issues, but it will be
awesome when the kinks are worked out.

>
> Is there any way to avoid this? Can you disable editing of the script files?
> Is there any way to revert the files if you accidentally change them and get
> your breakpoints back?

What happens if you use Control Z? That reverts changes for me.

jjb

[mobiDevJC]

Here are some more specific reproduction steps, if this is indeed a bug.

This is occurring on Chrome 19.0.1084.46 m for Windows 7 Enterprise 64bit.

1. Load a page with some scripts in .js files.

2. Open the developer tools script view.

3. Select a script and set a few breakpoints throughout.

4. Click in the body of the script file to place the cursor. 

5. Type a few characters

Result:

- An asterisk is now shown in the filename tab to indicate the file has been edited. 

- The normally dark blue breakpoint indicators turn to their faded blue disabled color.

- Breakpoints are removed entirely from the list. They are removed entirely, not just unchecked.

Additional details:

Selecting ctrl-z seems to always undo your typing. This will sometimes cause the breakpoints to reappear and the asterisk to go away. However, in most cases, while ctrl-z does undo the changes, the breakpoints do not reappear and the file continues to indicate that it's been edited.

Thanks,
JC

[John Barton]

On May 23, 3:26 pm, mobiDevJC <mobide...@gmail.com> wrote:
> Here are some more specific reproduction steps, if this is indeed a bug.
>
> This is occurring on Chrome 19.0.1084.46 m for Windows 7 Enterprise 64bit.
>
> 1. Load a page with some scripts in .js files.
> 2. Open the developer tools script view.
> 3. Select a script and set a few breakpoints throughout.
> 4. Click in the body of the script file to place the cursor.
> 5. Type a few characters
>
> Result:
> - An asterisk is now shown in the filename tab to indicate the file has
> been edited.

Yes, editor has set the "I am dirty" flag.

> - The normally dark blue breakpoint indicators turn to their faded blue
> disabled color.

Yes, breakpoints are suspended while you edit, restored when you save.

> - Breakpoints are removed entirely from the list. They are removed
> entirely, not just unchecked.

IMO this is a bug because the other time we see the breakpoints
disabled they do not disappear. I opened:
https://code.google.com/p/chromium/issues/detail?id=129526

>
> Additional details:
> Selecting ctrl-z seems to always undo your typing. This will sometimes
> cause the breakpoints to reappear and the asterisk to go away. However, in
> most cases, while ctrl-z does undo the changes, the breakpoints do not
> reappear and the file continues to indicate that it's been edited.

ctrl-z is undo so if you enter by mistake twice, two cntrl-z are
needed to undo both.

If you can provide a specific page and sequence where cntrl-z does not
revert the asterisk and breakpoint-disable we can fix this. (I've not
seen it myself).

jjb

>
> Thanks,
> JC

[PhistucK]

This was committed recently, it may help alleviate the issue -

http://trac.webkit.org/changeset/117965

☆PhistucK

[mobiDevJC]

Yes, breakpoints are suspended while you edit, restored when you save.

I tried saving the file. On a few occasions (maybe 10% of the time), it did appear to save the file and breakpoints reappeared and were again editable.

 and encountered an odd error message in the console 

 

IMO this is a bug because the other time we see the breakpoints
disabled they do not disappear. I opened:
https://code.google.com/p/chromium/issues/detail?id=129526

 Thanks. 

ctrl-z is undo so if you enter by mistake twice, two cntrl-z are
needed to undo both.

 

Sometimes, one ctrl-z will undo all the typing, but when it doesn't, I've made sure to use it until all the text changes are undone.

 

If you can provide a specific page and sequence where cntrl-z does not
revert the asterisk and breakpoint-disable we can fix this. (I've not
seen it myself).

The files with which I originally experienced the problem are currently confidential. I'll spend some time to find a public file that can be used to reproduce and will post it.

Thanks,
JC 

 

[mobiDevJC]

Sorry for the typo. I got to editing my post and left out an important bit.

I tried saving the file. On a few occasions (maybe 10% of the time), it did appear to save the file and breakpoints reappeared and were again editable.

However, on many occasions, I was not able to save the file. I would hit ctrl-s and encountered an odd error message in the console. Uncaught Script not found. This error would show up repeatedly and once it occurred, I was not able to save the file. This seems like it could be a separate, albeit possibly related bug. 

This bug seems related to this issue and possibly to the breakpoint problem as the reporter mentions he's unable to set breakpoints once he encounters the problem. 

http://code.google.com/p/chromium/issues/detail?id=92134

One thing to note is that I have only encountered the  Uncaught Script not found error when trying to save. It does not necessarily appear when I encounter the breakpoint issue I originally reported. 

[John J Barton]

On Thu, May 24, 2012 at 12:22 PM, mobiDevJC <mobi...@gmail.com> wrote:
> Sorry for the typo. I got to editing my post and left out an important bit.
>
>
> I tried saving the file. On a few occasions (maybe 10% of the time), it did
> appear to save the file and breakpoints reappeared and were again editable.
>
>
> However, on many occasions, I was not able to save the file. I would hit
> ctrl-s and encountered an odd error message in the console. Uncaught Script
> not found. This error would show up repeatedly and once it occurred, I was
> not able to save the file. This seems like it could be a separate, albeit
> possibly related bug.

This is also my experience. See below.

Note one workaround seems to work for some cases: resume from your
breakpoint then save again. This fails if you have syntax errors.

>
> This bug seems related to this issue and possibly to the breakpoint problem
> as the reporter mentions he's unable to set breakpoints once he encounters
> the problem.
>
> http://code.google.com/p/chromium/issues/detail?id=92134
>
> One thing to note is that I have only encountered the  Uncaught Script not
> found error when trying to save. It does not necessarily appear when I
> encounter the breakpoint issue I originally reported.

What is happening here is that your modified source is pushed back
into the V8 engine and it chokes on it. The exact reason for choking
varies, but the user experience is as you describe: the edit fails
with a mystery message.

We are working on this problem in two ways.

First, I am proposing a change in the edit user experience to separate
"edit" from "live-edit":
https://code.google.com/p/chromium/issues/detail?id=123242
The main effect would be that saving-while-on-a-breakpoint will always
work. Your changes will be saved to disk first and the LiveEdit work
will happen when you resume from the breakpoint. That way if the
LiveEdit fails, you just reload and get the new edits that way. As
LiveEdit gets better, the experience will get faster.

Second, we are working to improve the cases the LiveEdit can handle.
The general problem is a tough one. Key to success will be test cases
to cover the common use cases. I've entered some:
http://code.google.com/p/chromium/issues/list?can=2&q=johnjbarton+liveedit
Especially valuable are small test files and baby-step-by-baby-step
instructions to reproduce the issue.

jjb