FeatureDebugOnRealFiles

Introduction

This feature is important element of Debugger-IDE integration. By default Debugger works with source files it gets from remote VM -- a files under a temporary VirtualProject. (This means you never have to worry about getting sources for debugging).

However you also could be using Eclipse for developing your JavaScript program. In this case your sources are in file system and it absolutely makes sense to have debugger use them rather than downloaded copies: you code, you set a breakpoint, you see a problem, you fix it -- all in the same editor. An important detail: you can set a breakpoint on a file before script has been loaded and even before you attached to Chrome.

Technically speaking, you will need to establish source mapping in both directions: Debugger must know how a script in VM (already presented in the VirtualProject) is mapped to some local file and vice verse -- how a local file with breakpoint corresponds to a remote script. And it involves the directory structure both on remote and in local project.

Debugger has 2 approaches to deal with directory structures that are known as source look-up methods. You can select a method from "Remote" tab of launch configuration.

Auto-detect method

Here the source look-up is based on file short names. This is a bit fuzzy because it may fail on files with the same name in different directories and because Debugger takes a liberty to pick a short name from whatever remote VM sends to it (could be any string) and makes some other assumptions.

Configuring:

• select "Auto-detect" method in "Remote" tab of launch configuration,
• in the "Source" tab, add one or more folders holding your working files.

If all of your files in the project are called 'foo.js', this probably won't work correctly. However, for most projects there shouldn't be any problems.

Anyway, should you occasionally have a few files with the same name in different directories, there is a fall-back: you can configure Debugger to take a directory name into consideration for this particular file.

1. Open file properties (Alt+Enter) on your local file.

2. Use "Less" and "More" buttons to add or remove file path components. By default, only the file name is used, but you may add its parent directory or a longer path. All selected file path components will be used for matching this file.

Exact match method

This method accurately works with the full file path, so you would need to provide more details about your directory structure than in "Auto-detect" method.

First let’s see how V8 identifies those remote scripts. While debugging a script in the virtual project open “Properties” (context menu on file in “Project Explorer” or with Alt+Enter in an editor).

Here we see that VM identifies your script as URL http://server:8080/misc/utils.js (from this URL you seem to be running a local web server; there may be other configurations; in particular scripts may be from your disk, with file://... URLs). Depending on your working files layout, URLs like this should be mapped either as http://server:8080/misc/** => <your misc folder>/** or as http://server:8080/** => <your project folder>/**

You can configure this in "Edit Source Lookup..." on already running launch or in “Source” tab of your debug launch configuration for future runs:

Add a new source container with identifier mapping and make sure it is above the “Default” container (here “Default” container represents the virtual project that holds downloaded scripts). In the dialog window, choose “JavaScript Source Name Mapper” from the list. This container converts URL (or any id) into a file name and looks it up in another container, here called “target container”.

Depending on your configuration, enter the common URL prefix (e.g. http://server:8080/) and specify the target container (choose type and configure it).

Also make sure that you selected "Exact match" method in "Remote" tab of launch configuration,

See also a screen-cast video.

Known issues

For files in VirtualProject the dedicated editor was registered. Obviously this is not the case for files in your project. You can be using JSDT JavaScript editor or system Text Editor or any other. This brings up the following issues.

• The editor may not fully support breakpoint (like system Text Editor). You still can set them via Run | Toggle Breakpoint.
• There might be several types of breakpoints registered in Eclipse. In this case you have to hint the system which type you want: choose Chrome/V8 breakpoints in {{{Run | Breakpoint Types}} menu.

[Anonymous]

Originally posted by: tocr...@gmail.com

Hi there,

am I correct in assuming that only breakpoints set '''after''' the corresponding script was loaded into chromium are hit? At least that's what I observe -- once working breakpoints are ignored when clicking chromium's reload button...

Regards --

Torsten

[Anonymous]

Originally posted by: peter.ry...@gmail.com

Torsten, no, this shouldn't be like this. Breakpoint is expected to be registered in VM and actually set immediately after the script is loaded. This could be a bug though. I propose you submit an issue with some details. This way you will also get into a mail-loop. Alternatively, we could discuss it in a discussion group (see main page). Peter

[Anonymous]

Originally posted by: anega...@gmail.com

I can't get it working with local files: http://code.google.com/p/chromedevtools/issues/detail?id=63&thanks=63&ts=1330541070

[Anonymous]

Originally posted by: brunope...@gmail.com

Hi,

I don't see any "Source look-up method" in my configuration window, maybe the plugin was updated since you wrote this page ? Is there a workaround ?

Thanks in advance

[Anonymous]

Originally posted by: peter.ry...@gmail.com

yes, this option was moved to the other tab (Mapping I believe). The text is outdated, thank you for finding this. Peter

[Anonymous]

Originally posted by: azli...@gmail.com

I am unable to map to my real project files. Setting a breakpoint in my original source file works fine. However when the breakpoint is hit at runtime it opens the "Virtual Project" file and not the real one.

I have tried different "source mapper" settings alongside "Exact match" setting toggled on, but nothing will do. I am working on a Java webapplication project that gets deployed to an eclipse managed Tomcat server on localhost.

In source mapper I have tried https://localhost:8443/ as well as https://localhost:8443/MyProject/ With either Java Project, Project, Workspace folder etc.... as "Target Source container" but none of these did the trick of displaying the line breakpoint inside the original file. For now I fall back to "Automatic" script mapping which opens up the Virtual file but I'd really love to see it working the way it should ( I'd like :) ) .

What am I missing ? Any hints appreciated.

[Anonymous]

Originally posted by: peter.ry...@gmail.com

Hi Azlist1 Are you sure that your "source mapper" container is ordered above "Default" container in Source Lookup Path? If Default container goes first, it's natural that virtual file has a priority.

If this doesn't help, I suggest we continue in a mail group so that we don't miss new answers from each other.

Peter

[Anonymous]

Originally posted by: rghas...@gmail.com

Was any progress ever made with you issue azli? Anyone have a link to the mail group mentioned? I have a similar problem. I am able to set breakpoints in source files an have them hit, but they only open in the virtual project.

[Anonymous]

Originally posted by: pavelmaximov81@gmail.com

For all who is having problems with breakpoints set in Eclipse being ignored by Chrome check in Elcipse "Run > Breakpoint Type" is set to "Chrome /V8 breakpoints". If it was not, change the setting and recreate your breakpoints they will be of new the type and will work.

[Anonymous]

Originally posted by: ErnestJe...@gmail.com

when I click "Run>Breakpoint type", it says "None Available". any ideas?