chrome blackbox vm files
chrome debug async/await
chrome debugger skip line
chrome developer tools blackbox script
call stack chrome dev tools
another file titled "[VM] (8312)" popped up. I kept clicking "Step over to the next function call" and now my screen is:
What are these strange and mysterious scripts titled "[VM](XXXX " and where do they come from?
[VM] (scriptId) has no special meaning. It's a dummy name to help us to distinguish code which are not directly tied to a file name, such as code created using
eval and friends.
In the past, all of these scripts were just labelled
If you're interested, just look up
"[VM]"in the source code of Chromium, you will discover that these numbers have no significant meaning outside the developer tools.
Whenever you load HTML content through AJAX, and that content contains
<script> tags, the script will be evaluated using eval() and recognized by Chrome's Sources view as a new file beginning with 'VM'. You can always go to the Network tab, find the AJAX request, and view the HTML response in its entirety, including your script.
I found VM gets generated from some Chrome extensions - they insert CSS/JS into the page and Chrome uses the VM files to run it.
If you want to debug programmatically injected JS files in chrome you can use the
debugger; statement, this is faster than finding where your script is and also faster than generating a file with sourceurl.
It works like a breakpoint and automaticaly pinpoints your code in the chrome source tab wherever you use the
Note that the source of the script is a VMXXX file.
- These VM files also appear when you are editing files which are debugging at the same time. Chrome loses synch and when a breakpoint is put on the file it will stop the code at some other position in the file in memory somewhere. e.g. test.html will allow a breakpoint but when Chrome stops it does so at VM99:test.html at some other position. The solution is to close Chrome rename the files, e.g. test2.html, and start again. (Clearing history, cache etc doesn't work and Chrome will keep loading the VM99:test.html if you try that.
- Would Chrome hit the [VM] file instead of the live js file? If so, why?
- @Matt What do you mean by "Hit the [VM] file instead of the live js file"?
- @RobW disregard; my browser was caching the js file (despite having updated my cache buster).
[VM] (scriptId)was renamed to
VMscriptIda while ago, but I've kept the answer in its current state to not invalidate the question. The latest codesearch link is: cs.chromium.org/%22VM%5C%22%20+%22 (direct link to search result in case the value changes again: chromium.googlesource.com/chromium/blink/+/…)
- I recently encountered this problem without any eval - it appears to be related to the use of iFrames. My evidence for this is that when I set a breakpoint on code in an iFrame, I get the [VM] problem, but when I open the iFrame in its own window, I get hit the breakpoint just fine. Just sure if this qualifies as one of eval's "friends" as described in the answer.
- This sucks for debugging though. If I use a script tag with
src=/test.jsthen cause an error that traces back to test.js, the traceback contains the correct filename, but thereafter, stacktraces contain the VM magic. This makes it impossible to get the source code [from same origin] for the files in the stacktrace more than once, and you can't cache them, as you don't know which file is which in future stacktraces. This is fixed in Dev Tools, but not in webapps.
- The syntax has changed, now its: //# sourceURL=dynamicScript.js
- Been looking for something like this. Thanks
- Thank you! It's so useful!
- On Firefox debug tools, it says
Using //@ to indicate sourceURL pragmas is deprecated. Use //# instead