Javascript debugging not working via remote debugging?

[jami...@google.com]

Hi,

Is remote debugging of JavaScript code expected to work?  For me, on Chrome 22 beta (Linux) or 21 (Mac), remote debugging works nicely for examining the DOM structure, but not for working with JavaScript.

I'm working on event listeners that are hooked up to FOCUS/BLUR events, and remote debugging would be a great way to work with this code without the debugger window (e.g. just clicking "next line") disturbing focus.

Unfortunately, browsing the code doesn't work when connected remotely, and breaking on DOM changes only begins to work. I can right-click on an element of interest in the DOM view and select "break on attributes modification", go to the other Chrome instance and make the right JavaScript trigger; execution does pause, and I do see a stack trace, but the JavaScript source doesn't show up, and "resuming" doesn't actually free the target app to go forward. Instead, the target sits in "Paused in debugger" indefinitely.

(When hooking up a mac debugger view to a target chrome instance on Linux, via ssh, the pause/step buttons don't even show up - the keyboard shortcuts appear to work, though the target instance remains stuck.)

Any thoughts or recommendations on how to get this to work?  The javascript is served up dynamically by my app, which could present some complexity, though it works fine with conventional non-remote debugging.

Thanks!  

  -- Jamie

p.s. Chrome Devtools rock, by the way.

[Yury Semikhatsky]

On Wed, Sep 12, 2012 at 3:02 AM, <jami...@google.com> wrote:

Hi,

Is remote debugging of JavaScript code expected to work?  For me, on Chrome 22 beta (Linux) or 21 (Mac), remote debugging works nicely for examining the DOM structure, but not for working with JavaScript.

I'm working on event listeners that are hooked up to FOCUS/BLUR events, and remote debugging would be a great way to work with this code without the debugger window (e.g. just clicking "next line") disturbing focus.

Unfortunately, browsing the code doesn't work when connected remotely,

Does it mean that  you don't see scrips in the Sources panel?

 

and breaking on DOM changes only begins to work. I can right-click on an element of interest in the DOM view and select "break on attributes modification", go to the other Chrome instance and make the right JavaScript trigger; execution does pause, and I do see a stack trace, but the JavaScript source doesn't show up, and "resuming" doesn't actually free the target app to go forward. Instead, the target sits in "Paused in debugger" indefinitely.

I checked this with a couple of simple scenarios and it worked just fine for me like with in-browser debugger. Do you have a reproduction case that you could share with us?

[Jamison Gray]

Hi Yury,

On Tue, Sep 11, 2012 at 10:40 PM, Yury Semikhatsky <yu...@chromium.org> wrote:

On Wed, Sep 12, 2012 at 3:02 AM, <jami...@google.com> wrote:

Hi,

Is remote debugging of JavaScript code expected to work?  For me, on Chrome 22 beta (Linux) or 21 (Mac), remote debugging works nicely for examining the DOM structure, but not for working with JavaScript.

<snip>

Unfortunately, browsing the code doesn't work when connected remotely,

Does it mean that  you don't see scrips in the Sources panel?

Correct, the tabs in the Scripts panel are blank.

 

 

and breaking on DOM changes only begins to work. I can right-click on an element of interest in the DOM view and select "break on attributes modification", go to the other Chrome instance and make the right JavaScript trigger; execution does pause, and I do see a stack trace, but the JavaScript source doesn't show up, and "resuming" doesn't actually free the target app to go forward. Instead, the target sits in "Paused in debugger" indefinitely.

I checked this with a couple of simple scenarios and it worked just fine for me like with in-browser debugger. Do you have a reproduction case that you could share with us?

I'll see whether I can narrow it down, or whether it works for me with some simpler code setups. 

 

[Vsevolod Vlasov]

I have identified two problems here.

1) The original issue is caused by the 5MB limit to the socket buffer size: http://code.google.com/searchframe#OAMlx_jo-ck/src/net/base/stream_listen_socket.cc&exact_package=chromium&q=stream_listen_socket&type=cs&l=43

2) We have also found a text editor regression - it loads extremely slowly on huge files (several hundred of thousand lines).

--
Thank you,

Vsevolod Vlasov (vse...@google.com)

[Vsevolod Vlasov]

+pfeldman, who is working on the fix.

On Mon, Sep 24, 2012 at 9:52 PM, Jamison Gray <jami...@google.com> wrote:

Thanks, Vsevolod! Is there any way to work around the socket buffer size? From looking at the code, it looks like it's hardcoded rather than a configurable parameter...

[Jamison Gray]

Thanks, Vsevolod! Is there any way to work around the socket buffer size? From looking at the code, it looks like it's hardcoded rather than a configurable parameter...

On Thu, Sep 20, 2012 at 1:12 AM, Vsevolod Vlasov <vse...@google.com> wrote:

[Pavel Feldman]

I'm working on fixing it. It involves restoring the blocking socket implementation and running our server in the new thread. Hold on, I'm planning to complete it this week.

Regards

Pavel

[Jamison Gray]

Hi Pavel,
Just checking in - any update on when remote debugging will be usable
with Gmail's code size?

Let me know if there's any way I can help - Aliese Zacharias sent some
test account info to @yuriys and @vsevik that will give access to a
debug-enabled version of Gmail.

Regards,
-- Jamie

[mikewa...@google.com]

Any update on this? Would it be worth having one of us try again to see if remote debugging is feasible for Gmail?

[Pavel Feldman]

Please do. I fixed the buffer limitation a while ago and it should work now.

Regards
Pavel

[mikewa...@google.com]

I'm able to perform basic functions, like inspecting elements, setting, and triggering breakpoints. Thanks Pavel.