Closed GoogleCodeExporter closed 8 years ago
Show be implemented in upcoming 0.1.6 release.
Already done in HEAD.
Original comment by peter.ry...@gmail.com
on 3 Aug 2010 at 9:34
Original comment by peter.ry...@gmail.com
on 10 Aug 2010 at 8:37
Hi, Peter
I can't get any editing to happen.
I'm using the convention of clicking on the script.js file to open it, modify
it, and save it. No corresponding change happens on disk to change the
javascript source.
The .js file appears in an Eclipse 'project' correctly after loading a local
page in an instance launched like...
chromium-browser --remote-shell-port=9222
The path to the local page is
file:///home/cefn/Documents/code/tacticalendar/velcrotester/index.html, which
already has enough information in it, but I've also added a source path
association within the Debug configuration to point to full directory path as
well.
After editing (it warns me I'm making it writable and I click yes), saving has
no effect on the source file at all.
Original comment by google....@cefn.com
on 7 Oct 2010 at 12:54
Additionally I've tried creating a 'Javascript Source Mapper' in the debug
container with the following values...
Prefix: file:///home/cefn/Documents/code/tacticalendar/velcrotester/
(value copy pasted from Chrome location bar)
Target Source Container: Filesystem Directory:
/home/cefn/Documents/code/tacticalendar/velcrotester/
(value derived from interactively navigating to velcrotester directory through
Eclipse UI).
What's probably worst of all, is that the Eclipse environment asks me if it
should make the file writeable, and writes it somewhere when you choose save.
However, the text added is lost since it doesn't in fact save it to the
original file in the source directory.
Original comment by google....@cefn.com
on 7 Oct 2010 at 1:13
Additionally I've tried running Chrome against a localhost webserver, such that
the URL http://localhost:3333/index.html points to the local source at
file:///home/cefn/Documents/code/tacticalendar/velcrotester/index.html
After creating a corresponding source mapper from the prefix
http://localhost:3000/ to the source directory, source edits to files loaded in
the virtual project created by the Chrome debugger still fail to write to the
disk.
Original comment by google....@cefn.com
on 7 Oct 2010 at 1:24
Hi
There's a misunderstanding here. The idea is that you should import your local
files into Eclipse and edit THEM in a normal way, with or without debugger
attached. When debugger attaches, it always downloads the scripts from remote
VM and puts them into another "virtual" project.
However, with a help of Source Mapper you tell Eclipse to use YOUR files rather
than downloaded files. It works when Eclipse highlights current statement and
for breakpoints.
Please feel free to ask further if needed.
Peter
Original comment by peter.ry...@gmail.com
on 7 Oct 2010 at 2:16
Like anyone else using this functionality, I think I'm going to need a detailed
case which DOES work.
There's a million ways to attempt to make it work, and I must have tried a half
million of them, which is unnecessary since there must be documented cases
already, though I don't know where. A google search doesn't find them, and no
links have been offered in this thread.
If you are aware of a precise sequence which is tested and achieves interactive
editing within a debugger session, then please share it and I can start from
there.
At the moment, I am finding that a chromium debugger session is unable to
introduce functioning breakpoints into *.js.chromium sourcefiles at all, using
the interface convention which I'm familiar with from Eclipse Java and Aptana
Javascript debugging.
This means, of course, that I can't test your assertion that breakpoints hit
with a successful source mapping will associate with the files in my ordinary
Eclipse project (I've set up a source mapper as precisely as I can, but I don't
think it's even reaching this stage).
After loading the files by visiting a page in the browser, like...
http://localhost:3000/allyourx/test/unit.html
...and launching the Chromium Debugger, some of the javascript files appear in
the dynamically generated Chromium Debugger project in Eclipse.
All of them are evaluated, else the unit tests wouldn't work, but only some of
them show up.
Reloading the same page in the browser causes the remainder of the files to
appear in the Chromium Debugging project.
Then navigating to a .js file, you can add breakpoints and they appear in the
breakpoints list. Reloading the page to rerun the scripts and hit the
breakpoints then causes the blue circles to disappear from the source file,
although they remain in the breakpoint list. They are never hit and no stack
appears in the Eclipse debugger.
Chromium JavaScript Remote Debugger 0.1.6.201008092223
Chromium 7.0.517.41 (62167) Ubuntu 10.04
Eclipse SDK Version: 3.5.2 Build id: M20100211-1343
Original comment by google....@cefn.com
on 30 Oct 2010 at 8:09
If it's in any way relevant for recreating the scenario, the source I'm trying
to run tests on and modify is available at...
http://github.com/cefn/allyourx
The source needs to be run from a http server as the unit test themselves
violate the browser security model if they try to load files from file:// URLs.
A whole host of the tests in the allyourx/test/unit.html suite run OK, but some
are still red so that's normal (I'm in test-driven mode).
Original comment by google....@cefn.com
on 30 Oct 2010 at 8:15
Same issue occurs without a page refresh between adding the breakpoint and the
breakpointed code executing.
Steps;
* add an alert dialog to halt execution after files are loaded into the
Chromium Debugger project but before the target line
* interactively insert a breakpoint at the target line within one of the
dynamically created *.js.chromium source files files a few lines after the
alert(...) call.
The breakpoint is still never hit.
Exactly the same issue occurs when using google-chrome in the place of
chromium-browser.
Original comment by google....@cefn.com
on 30 Oct 2010 at 8:29
Hi
Can I ask you please to summarize your problem description more or less in form
of step list? It's not really clear what one should do to reproduce a problem.
E.g. we are discussing local working files problem; however, you are mentioning
that you cannot set a breakpoint on "*.js.chromium" file, which should be a
virtual project file, not the local file.
Thanks
Peter
Original comment by peter.ry...@gmail.com
on 1 Nov 2010 at 1:41
And yes, I agree that we do need a good tutorial for the whole tool.
Unfortunately currently we only have a very brief description at
http://code.google.com/p/chromedevtools/wiki/Release_0_1_6
Original comment by peter.ry...@gmail.com
on 1 Nov 2010 at 1:44
Original issue reported on code.google.com by
google....@cefn.com
on 18 Jul 2010 at 12:28