Я добавил точку останова в свой файл javascript (jaydata.js) и нажимал «Перейти к следующему вызову функции». Когда дошло до строки:
},
появился другой файл с названием «[VM] (8312)». Я продолжал нажимать «Перейти к следующему вызову функции», и теперь мой экран:
Что это за странные и загадочные скрипты с названием «[VM] (XXXX» и откуда они взялись?
Ответы:
[VM] (scriptId)не имеет особого значения. Это фиктивное имя, которое помогает нам различать код, который напрямую не привязан к имени файла, например код, созданный с помощью evalи друзей.
Раньше все эти скрипты были просто помечены (program).
Если вам интересно, просто посмотрите "[VM]"исходный код Chromium , вы обнаружите, что эти числа не имеют никакого значения за пределами инструментов разработчика.
[VM] (scriptId)был переименован в VMscriptId некоторое время назад , и вот прямая ссылка на результат поиска на случай, если значение снова изменится.
[VM] (scriptId)был переименован VMscriptId некоторое время назад , но я сохранил ответ в его текущем состоянии, чтобы не сделать вопрос недействительным. Последняя ссылка codesearch является: cs.chromium.org/%22VM%5C%22%20+%22 (прямой ссылкой для поиска результата в случае , когда значение изменяется снова: chromium.googlesource.com/chromium/blink/+/... )
Каждый раз, когда вы загружаете HTML-контент через AJAX и этот контент содержит <script>теги, сценарий будет оцениваться с помощью eval () и распознаваться представлением источников Chrome как новый файл, начинающийся с «VM». Вы всегда можете перейти на вкладку «Сеть», найти запрос AJAX и просмотреть HTML-ответ целиком, включая ваш скрипт.
src=/test.jsthen, вызывает ошибку, которая ведет к test.js, трассировка содержит правильное имя файла, но после этого трассировки стека содержат магию виртуальной машины. Это делает невозможным получение исходного кода [из одного и того же источника] для файлов в трассировке стека более одного раза, и вы не можете их кэшировать, так как вы не знаете, какой файл является каким в будущих трассировках стека. Это исправлено в Dev Tools, но не в веб-приложениях.
При использовании eval javascript попадает в виртуальные машины Chrome Debugger. Чтобы просмотреть js-файлы, созданные с помощью eval, в Chrome Debugger Sources, установите этот атрибут в конце (спасибо Splaktar) js:
//@ sourceURL=dynamicScript.js
Using //@ to indicate sourceURL pragmas is deprecated. Use //# instead
Если вы хотите отлаживать программно внедренные JS-файлы в chrome, вы можете использовать debugger;инструкцию, это быстрее, чем поиск вашего скрипта, а также быстрее, чем создание файла с sourceurl .
Он работает как точка останова и автоматически определяет ваш код на вкладке исходного кода Chrome, где бы вы ни использовали debugger;оператор.
Обратите внимание, что источником сценария является файл VMXXX.
debugger;заявления он может демистифицировать, откуда берутся загадочные «странные и таинственные сценарии под названием« [VM] (XXXX »», если он того пожелает.
Я столкнулся с той же проблемой. Проблема в том, что код моего приложения случайно оказался черным ящиком. Когда я пытался войти в код, он продолжал открывать эти VMXXXXвкладки.
После удаления настройки черного ящика для js-файла моего приложения я мог успешно выполнить свой код.
для предотвращения этого
(function ()
{
var originalEval = eval;
eval =
function (script)
{
return originalEval(script + "\n//# sourceURL=blackbox-this.js");
}
}());
А потом черный ящик ^.*blackbox-this.js$
То же самое для setInterval / setTimeout, когда он получает строку (но в любом случае это плохая практика, верно?;))
Это работает для вас?
У меня была такая же проблема, когда я отлаживал свое угловое приложение. Отладка слишком большого количества сценариев виртуальных машин, которые нельзя было поместить в черный ящик, действительно занимала много времени. Для отладки я выбрал обозреватель Mozilla / IE.