Chrome paused in debugger отключить
Давайте отвлечёмся от написания кода и поговорим о его отладке.
Отладка – это процесс поиска и исправления ошибок в скрипте. Все современные браузеры и большинство других сред разработки поддерживают инструменты для отладки – специальный графический интерфейс, который сильно упрощает отладку. Он также позволяет по шагам отследить, что именно происходит в нашем коде.
Мы будем использовать браузер Chrome, так как у него достаточно возможностей, в большинстве других браузеров процесс будет схожим.
Перехват запросов
Что делать если вы ковыряете чужой ресурс и хотите перехватить запрос. Я думаю, тут есть много рецептов. Здесь я опишу такой, который не требует никаких сторонних расширений\приложений.
Находим нужный запрос в network-вкладке и наводим на него мышью:
Кликаем по 1-й (не обязательно) из ссылок, попадая в то место, где этот запрос был вызван. Ставим точку останова. Воспроизводим нужные действия в UI, чтобы этот запрос перевызвать.
Наверняка есть и более удобные способы перехватить запрос. Поделитесь вашим рецептом в комментариях!
PopUps, popovers, dropdowns и прочие "всплывашки"
Начну с простого. Я думаю, многие сталкивались с ситуацией, когда у вас есть какая-нибудь "всплывашка", и вам нужно что-нибудь в ней поковырять. Но вот незадача - стоит убрать фокус из окна вкладки, как всплывашка тут же пропадает. Если код полностью под вашей властью, то можно просто отключить механизм сокрытия на onBlur . А если нет?
Вот простое решение (upd: вот решение получше от @kamre):
Запускаем: setTimeout('debugger;', 3_000)
Успеваем за эти три секунды активировать всплывашку
debugger тормозит вкладку
Всплывашка в вашем полном распоряжении
upd от @ChernovKirilo: в ряде окружений можно решить вопрос даже проще. Достаточно активировать режим "сделать скриншот области экрана". Перед тем как сделать скриншот весь экран перегораживает "подсветка" (overlay). Она может не вызвать onBlur , так что "всплывашка" не потухнет. Но при этом позволит вам сдвинуть курсор мыши за пределы страницы:
Активируем скриншот-утилиту (например. кнопка PrintSrcreen на Windows)
Передвигаем курсор за пределы страницы (например на панель devTools)
Отменяем скриншот (Esc?)
Всплывашка в вашем полном распоряжении
Бесконечный цикл
Начнём с того - как же убить вкладку?
Запускаем Task Manager ( Shift + Esc ). Его можно найти в "главном меню" - "More Tools" - "Task Manager".
Находим искомую вкладку в списке, выделяем.
Жмём кнопку "End Process". Вкладка убита.
Хорошо, а что если мы не хотим её убивать?
Кликаем на "Pause"
Теперь вы в процессе отладки JS. Самое время понять причину бага. Разобрались? Отлично. Что дальше? Вы хотите вернуть эту же вкладку к жизни, потому что на странице есть важные данные или условия для эксперимента? Но вам мешает этот чёртов вечный цикл?
Просто "сломайте" код. Во время отладки вы можете запускать произвольный JS код в консоли. При этом у вас есть доступ к локальным переменным того участка кода, который сейчас остановлен.
Вы можете попробовать запустить что-то вроде throw 'error' , но скорее всего это вам ничего не даст, т.к. ваши команды в консоли обёрнуты в try-catch . Но можно сломать какой-нибудь объект. Предположим у вас там есть объект obj , и у него есть поле-метод field . Код использует его так: obj.field() . Прекрасно, пишем obj.field = null , запускаем JS, код падает, в консоли ошибка, вечный цикл побеждён. Понятное дело, что способов всё поломать тысячи, просто выберите нужный.
Дебажим JavaScript
Откровенно говоря, отладка кода может занимать много времени. Особенно, если использовать такие простые команды как console.log() или window.alert().
Нужно писать, а потом удалять дополнительный код, а иногда эти команды все равно попадают в коммит (даже если вы думали, что все их забрали). А если при этом использовать линты (статические отладчики), то команды console или alert будут подсвечиваться в коде.
И на этом моменте в игру вступает Chrome DevTools, позволяя нам дебажить код без утомительных команд. Среди фишек этой тулзы, редактирование CSS и HTML, тестирование сети и проверка скорости сайта — наши любимые.
Чтобы на практике познакомиться с этой тулзой, давайте создадим простенькую страничку на JavaScript с getData() методом. Этот метод будет просто собирать данные с поля ввода, создавать DOM элемент с dataSpan ID и добавлять значение с поля ввода в этот элемент.
Вот как наша страничка будет выглядеть:
В JavaScript:
Сохраним ее как app.js.
Вот как наша страничка будет выглядеть в браузере:
Чтобы проверить как метод работает до того, как сохранять данные в dataSpan, можно использовать старомодные console.log(data) или window.alert(data). Вот что мы увидим запустив файл в VS Code:
Это самый примитивный подход.
Вместо этого, мы используем брейкпоинты (точки останова) вChrome DevTools чтобы убедиться, что все работает как надо.
Брейкпоинт — это строка кода, на которой мы хотим приостановить прогонку кода, чтобы изучить как он работает (или не работает).
Возвращаясь к примеру, давайте запустим страницу в Google Chrome и сделаем следующее:
- Чтобы открыть Chrome Developer Tools, в правом верхнем углу браузера, кликнем чтобы открыть меню настроек.
- В этом меню, выберем Дополнительные инструменты (в английском меню — More tools), а потом Инструменты разработчика (Developer tools).
Открыв панель инструментов разработчика, давайте приостановим код на брейкпоинте:
- Выберите вкладку Sources.
- В Sources, в панели Page, выберите app.js (который мы создали чуть раньше).
- В редакторе кода, кликните на номер строки let data =document.getElementById('name').value;
Выжимка
В начале мы рассмотрели команды console.log() и window.alert() и поняли, что они не слишком удобны. Нужно было их часто использовать по всему коду, что могло сделать код «тяжелее» и медленнее, если бы мы забыли их удалить перед коммитом.
Когда количество строк растет, Chrome Developer Tools намного более эффективен для отлова багов и оценки работы в целом.
Это всё?
Если вам понравился этот материал и вы хотите продолжения - дайте знать. У меня ещё много всего в черновиках. Если у вас есть свои трюки\рецепты\хаки - пишите их в комментариях. Думаю многие найдут их полезными и применят в деле.
Если вы нашли синтаксическую\стилистическую ошибку (или тонну таких ошибок) прошу обращаться в личку (а не в комментарии).
Очень много сервисов сейчас позволяют дебажить код над фронтенде. Chrome DevTools и Firefox Developer Tools среди них самые популярные, но и в других браузерах тоже есть свои тулзы. Мы будем использовать Chrome DevTools для примеров.
HotFix-ы посредством breakpoint-ов
Механизм тот же самый. Предположим вы отлаживаете один баг, но в процессе отладки обнаружили другой, который всё портит, и вы не хотите на него отвлекаться. А ещё вы не хотите перезагружать вкладку, т.к. эту ситуацию вы потом уже не воспроизведёте. Что делать? Можно в breakpoint-условии написать что-нибудь, что чинит второй баг.
Например, что-нибудь ломается из-за отсутствующего метода. Ок, напишите в условии (obj.nonExistingMethod = () => null) && null . Код временно "починился". && null нужен только для того, чтобы breakpoint не останавливал исполнение JS.
Таким образом можно добиться очень многого. Зависит уже от вашей фантазии и сложности отладки. Ключевое:
нет нужды перезагружать вкладку (это может быть бесценным).
breakpoint-условие будет послушно запускаться всякий раз когда JS-интерпретатор будет добираться до breakpoint-а. По сути это аналогично тому что вы добавили строку кода ровно туда, куда нужно, ничего по факту не добавляя.
Настраиваем дебаггер
Для начала, нам нужно будет настроить дебаггер:
1. С File Explorer перейдите на Debug вкладку.
Также можно использовать для этого Ctrl+Shift+D.
2. Кликните на иконку Settings чтобы создать launch.json.
Это файл с настройками, который мы будем использовать.
3. С выпадающего меню Select Environment выберите Chrome.
Это создаст новую папку .vscode и файл launch.json для вашего проекта.
4. Запустите этот файл.
5. Чтобы использовать этот файл для наших целей, в методе url замените localhost порт с 8080 на 4200.
6. Сохраните изменения.
Вот как должен выглядеть файл:
7. Нажмите F5 или кликните кнопку Start Debugging чтобы запустить Debugger.
8. Запустите Chrome.
9. Чтобы приостановить выполнение кода на брейкпоинте, обновите страницу.
Чтобы последовательно просмотреть выполнение кода и как меняются переменные, используйте клавишу F10.
Остановимся и оглядимся
В нашем примере функция hello() вызывается во время загрузки страницы, поэтому для начала отладки (после того, как мы поставили точки останова) проще всего её перезагрузить. Нажмите F5 (Windows, Linux) или Cmd + R (Mac).
Выполнение прервётся на четвёртой строчке (где находится точка останова):
Чтобы понять, что происходит в коде, щёлкните по стрелочкам справа:
Watch – показывает текущие значения для любых выражений.
Вы можете нажать на + и ввести выражение. Отладчик покажет его значение, автоматически пересчитывая его в процессе выполнения.
Call Stack – показывает цепочку вложенных вызовов.
В текущий момент отладчик находится внутри вызова hello() , вызываемого скриптом в index.html (там нет функции, поэтому она называется “анонимной”).
Если вы нажмёте на элемент стека (например, «anonymous»), отладчик перейдёт к соответствующему коду, и нам представляется возможность его проанализировать.
Scope показывает текущие переменные.
Local показывает локальные переменные функций, а их значения подсвечены прямо в исходном коде.
В Global перечисляются глобальные переменные (то есть вне каких-либо функций).
Там также есть ключевое слово this , которое мы ещё не изучали, но скоро изучим.
Логирование
Чтобы вывести что-то на консоль из нашего кода, существует функция console.log .
When debugging in chrome, the scripts are always paused in the debugger even if there are no break points set, and if the the pause is un-paused, it again pauses itself.
What can be done?
README
В расширении Debugger для Chrome есть множество дополнительных конфигураций, работа з source maps и устранений всяческих неполадок. Чтобы просмотреть их прямо в VS Code, кликните на расширение и выберите вкладку Details.
Более сложная отладка
Предположим, что мы выполняем функцию посложнее, которую точно не помешает отладить. К примеру, мы хотим, чтобы пользователи вводили числа через пробел. Функция затем будет обрабатывать и выводить эти числа, их сумму, и результат умножения.
Для этого мы обновим код app.js как на скриншоте выше. Обновляем страницу и приступаем непосредственно к дебаггингу.
- Кликните 3 (номер строки of let data = document.getElementById('name').value;) чтобы поставить брейкпоинт.
- Введите 23 24 е в строке ввода в браузере.
- Кликните Step over next function call.
Имена собственные
Если вы используете sourceMaps, то код, которые на самом деле исполняется, и тот который вы видите перед глазами могут очень сильно отличаться. В частности это касается имён локальных переменных. Пример:
Что будет если в консоли выполнить setState ?
И как теперь это дебажить? А чёрт его знает. Но могу дать пару советов.
1-й: поищите настоящие имена вот здесь:
upd от @extempl: не всегда новые наименования это одна\две буквы. К примеру для поддержки ES6 Import/Export webpack даёт вот такие длинные названия:
Чтобы упростить себе жизнь, можно нажать на ней (в панели Scope ) RightMouseClick и выбрать "Store object as global variable". DevTools выдаст вам новую переменную вида temp1 .
2-й: отключите sourceMaps (это можно делать live, без перезагрузки страницы):
3-й (от @mrShadow): в ряде случаев можно добраться до аргументов функции через arguments[index] .
SourceMap очень часто усложняют отладку до уровня nightmare. У @vintage где-то (где кстати?) была хорошая статья по этому поводу. Там объясняется почему SourceMap такие плохие, когда дело касается отладки. Я сам то и дело включаю\выключаю эту галочку, в зависимости от обстоятельств.
Кстати говоря, если вас смущает поведение отладчика в казалось бы нормальном коде, посмотрите как он выглядит на самом деле. Там нередко случаются цепочки с оператором , , незапланированные ?: . Часть условий может быть перестроена. Проще говоря код может разительно отличаться от оригинала. Хорошо когда если есть возможность избежать минификации.
Логирование при помощи breakpoint-ов
Тут всё просто. Не обязательно расставлять в кодовой базе console.log() , когда можно это сделать прямо в DevTools. Дело в том что у breakpoint-ов бывают условия:
Если условие задано, то breakpoint остановит исполнение JS только если его значение truthy. Напишите в условие console.log(whatever) . Всё. Т.к. console.log всегда возвращает undefined то ваш breakpoint никогда не остановит JS, но зато всегда будет послушно логировать.
upd: Оказалось, что для логирования есть отдельная опция "Add logpoint":
По сути тоже самое, но без необходимости писать console.log( . Да и помечаются розовым цветом, а не синим или оранжевым. В графе breakpoints они тоже отображаются (т.е. это по сути сахар поверх обычных breakpoint-ов).
Консоль
При нажатии на клавишу Esc в нижней части экрана вызывается консоль, где можно вводить команды и выполнять их клавишей Enter .
Результат выполнения инструкций сразу же отображается в консоли.
Например, результатом 1+2 будет 3 , а вызов функции hello("debugger") ничего не возвращает, так что результатом будет undefined :
Дебажим Angular
Легче всего отладить код Angular — использовать Visual Studio Code (VS Code). Чтобы начать дебаггинг, вам нужно будет установить расширение Debugger для Chrome:
- Запустите проект на VS Code и откройте вкладку Extensions. Или нажмите Ctrl+Shift+X на клаве.
- В строке поиска введите Chrome.
- Выберите Debugger for Chrome и кликните Install.
- После того как установите расширение, появится кнопка Reload. Кликните ее, чтобы завершить инсталляцию и активировать Debugger.
Breakpoint посреди строки
Не все замечали, но Chrome DevTools позволяют выставить breakpoint не на всю строку, а в какую-нибудь её часть:
Это может сэкономить вам кучу времени.
Панель «Исходный код» («Sources»)
Версия Chrome, установленная у вас, может выглядеть немного иначе, однако принципиальных отличий не будет.
- Работая в Chrome, откройте тестовую страницу.
- Включите инструменты разработчика, нажав F12 (Mac: Cmd + Opt + I ).
- Щёлкните по панели Sources («исходный код»).
При первом запуске получаем следующее:
Кнопка-переключатель откроет вкладку со списком файлов.
Кликните на неё и выберите hello.js в дереве файлов. Вот что появится:
Интерфейс состоит из трёх зон:
- В зоне File Navigator (панель для навигации файлов) показаны файлы HTML, JavaScript, CSS, включая изображения, используемые на странице. Здесь также могут быть файлы различных расширений Chrome.
- Зона Code Editor (редактор кода) показывает исходный код.
- Наконец, зона JavaScript Debugging (панель отладки JavaScript) отведена для отладки, скоро мы к ней вернёмся.
Чтобы скрыть список ресурсов и освободить экранное место для исходного кода, щёлкните по тому же переключателю .
Ключевое слово “debugger”
Если ввести debugger в любом месте кода, Chrome DevTools приостановит выполнение кода на этой строке и подсветит ее также, как и брейкпоинты. Можно использовать этот инструмент чтобы дебажить JavaScript в Chrome или других браузерах. Только не забудьте удалить его, когда закончите отладку.
Код на скриншоте выше остановится на строке, которая содержит ключевое слово debugger и автоматически запустит Chrome DevTools. По сути, это то же самое, что и поставить брейкпоинт на эту строку. Также выполнением кода можно управлять с помощью кнопок Step into next function call и Step over next function call.
Как еще можно поставить брейкпоинты
В большинстве случаев, ваш код намного длиннее и, вполне возможно, конкатенирован в одну строку. К примеру, предположим, что у вас 1000 строк кода. В этом случае, ставить брейкпоинты, кликая на номера строк каждый раз, не кажется такой уж отличной идеей, не правда ли?
Для этого в DevTools есть классный инструмент для установки брейкпоинтов на разные типы интеракции с браузером. На панели JavaScript Debugging, кликните Event Listener Breakpoints чтобы посмотреть доступные категории.
Как вы видите, можно поставить брейкпоинт на событие Mouse > click (клик мышкой) в любом месте нашего кода. Это означает, что, если кликнуть Get Input Data, выполнение кода остановится на событии onclick. И не нужно вручную ничего добавлять.
Клик на Step over next function call будет последовательно вести нас через код, используемый чтобы обработать клики.
Используя Event Listener Breakpoints, можно поставить брейкпоинты на кучу разных типов событий, таких как Keyboard, Touch, и XHR.
ОТВЕТЫ
Ответ 1
Одна из возможных причин, что вы включили "паузу на исключениях" (значок маленькой стоп-знака с символом паузы (||) с в левом нижнем углу окна). Попробуйте щелкнуть по нему, чтобы вернуться в состояние off/gray (не красное или голубое состояние) и перезагрузить страницу.
Ответ 2
В моем случае у меня установлен флаг Any XHR true в настройках XHR Breakpoints , доступный на вкладке "Источники" в инструментах Chrome dev.
Снимите флажок, чтобы Chrome работал нормально снова.
Ответ 3
Это также может вызвать проблему
Значок точки разрыва в правом верхнем углу должен быть синим, как этот
Не должно быть серым, как это
Ответ 4
И есть несколько вариантов ниже, если вы проверили некоторые, когда это условие активно, отладчик точки останова также активен
Ответ 5
Если вы перейдете в раздел "Источники", вы увидите кнопку паузы внизу DevTools. В принципе, в DevTools есть 3 варианта паузы при отладке js файла,
Не приостанавливать исключения ():
Кнопка паузы будет иметь цвет серый, как если бы функция "Не останавливать на исключениях" активна.
Приостановить все исключения ():
Кнопка паузы будет иметь цвет синий, как если бы активна функция "Пауза для всех исключений".
Пауза на неперехваченных исключениях ():
Кнопка паузы будет находиться в фиолетовом цвете, как будто активна опция "Пауза на неперехваченных исключениях".
В вашем случае, если вы не хотите делать паузу, выберите "Не приостанавливать исключения". Чтобы выбрать, переключите кнопку паузы, пока она не станет серой .
Ответ 6
Угу. Я просто изучаю инструменты chrome dev сегодня и нашел то же самое - если выше не удается, разверните область, изображенную здесь, и найдите точки останова, которые вы, возможно, установили и забыли.
Ответ 7
Нажмите на значок "Настройки", затем нажмите кнопку "Восстановить настройки по умолчанию и перезагрузить". Это сработало для меня, тогда как принятый ответ не сделал.
Ответ 8
В правом верхнем углу второй последний значок (окруженный красным цветом в прикрепленном изображении) предназначен для активации/деактивации отладки. Нажмите, чтобы переключать отладку в любое время.
Ответ 9
Другой пользователь упомянул об этом небольшими подробностями, но я пропустил его, пока я не вернулся сюда примерно 3 раза в течение 2 дней -
Существует раздел под названием "Контрольные точки EventListener", который содержит список других точек останова, которые могут быть установлены. Бывает, что я случайно включил одну из них в DOM Mutation, которая давала мне знать, когда что-либо в DOM было переопределено. К сожалению, это привело к тому, что я отключил кучу плагинов и надстроек, прежде чем понял, что это всего лишь моя машина. Надеюсь, это поможет кому-то еще.
Ответ 10
Действительно глупая проблема, с которой я столкнулся, привел меня сюда с отладчиком; command.: "debugger;" на нем установлены часы.
Это вызвало страницу, которая только что сказала отладчика; чтобы отображаться между загрузкой каждой страницы.
Чтобы отключить его, просто нажмите правой кнопкой мыши на "Наблюдение" и нажмите "Удалить выражение".
Ответ 11
Это действительно плохой опыт. если вышеупомянутый ответ не сработал, попробуйте это.
Нажмите на значок "Настройки", затем нажмите кнопку "Восстановить настройки по умолчанию и перезагрузить".
Нажмите "F8", пока он не станет нормальным.
Ответ 12
Вы можете просто перейти в Breakpoints в консоли разработчика Chrome, щелкнуть правой кнопкой мыши и удалить точки останова. Простой.
Ответ 13
Вы можете нажать CTLR + F8 , чтобы активировать или деактивировать точки взлома.
Это короткое решение.
Ответ 14
В моем цикле for произошла синтаксическая ошибка. Это вызвало ошибку паузы.
Disable cache
Думаю большинство из нас знакомы с этой галочкой:
Здесь я хотел бы отметить, что не стоит на постоянной основе ей пользоваться. Дело в том, что такое поведение браузера очень далеко от нормального. Браузер перестаёт пользоваться не только старым кешем, оставшимся от предыдущей страницы, но и новым. Если покажете картинку, удалите её, а потом снова создадите с тем же SRC, то у вас будет два запроса.
Если на постоянной основе всё тестировать без кеша, то многие хитрые баги, которых просто не будет при отключённом кешировании, уйдут в production. И вот там их обнаружить и отладить может быть уже не тривиально.
Помимо прочего это мешает работать любой логике где есть подготовительные стадии с прогревом кеша. Например когда перед показом изображения вы где-нибудь успеваете его загрузить посредством new Image() .
В целом рекомендую поглядывать на запросы во вкладке network. Например можно случайно обнаружить, что отключён gzip/brotli. Или что CDN перестал присылать cache-control заголовок. Или что ещё вчера страница загружала 1 MiB, а сегодня 12 MiB (например какой-нибудь серверный endpoint стал присылать тонны JSON-а).
Отладка бекенда (Node.js)
Здесь вы узнаете как дебажить код на Node.js. Вот самые распространённые подходы:
• Используя Chrome DevTools
На даный момент, это наш любимый подход.
• Используя IDE-шки типаVisual Studio Code, Visual Studio, WebStorm, и т.д.
Для примеров мы будем использовать VS Code и Chrome DevTools.
Chrome и Node.js используют тот же JavaScript-движок, Google V8, и это значит, что для бекенда мы будем использовать те же инструменты, что и для фронта.
1. Запустите свой проект в VS Code.
2. Перейдите на вкладку Console.
3. Введите команду npm start --inspect и нажмите Enter.
4. Проигнорируйте предлагаемый “chrome-devtools://…” URL (существует метод получше).
5. Запустите Chrome и введите “about:inspect”.
Это перенаправит вас на вкладку Devices на DevTools.
6. Кликните линк Open dedicated DevTools for Node.
Процесс отладки такой же, как и для фронтенда, то есть с использованием брейкпоинтов. На самом деле, очень удобно то, что не нужно переключаться на IDE. Таким образом, можно дебажить и фронт- и бекенд на одном интерфейсе.
Спасибо за чтение и надеемся, что вам понравился этот пост. Подписывайтесь на обновления — у нас в рукавах еще полно полезностей :-)
При отладке в хром скрипты всегда приостанавливаются в отладчике, даже если нет установленных точек останова, и если пауза не приостановлена, она снова приостанавливается.
Что можно сделать?
Точки останова (breakpoints)
Давайте разберёмся, как работает код нашей тестовой страницы. В файле hello.js щёлкните на номере строки 4 . Да-да, щёлкайте именно по самой цифре, не по коду.
Ура! Вы поставили точку останова. А теперь щёлкните по цифре 8 на восьмой линии.
Вот что в итоге должно получиться (синим это те места, по которым вы должны щёлкнуть):
Точка останова – это участок кода, где отладчик автоматически приостановит исполнение JavaScript.
Пока исполнение поставлено «на паузу», мы можем просмотреть текущие значения переменных, выполнить команды в консоли, другими словами, выполнить отладку кода.
В правой части графического интерфейса мы видим список точек останова. А когда таких точек выставлено много, да ещё и в разных файлах, этот список поможет эффективно ими управлять:
- Быстро перейдите к точке останова в коде (нажав на неё на правой панели).
- Временно отключите точку останова, сняв с неё галочку.
- Удалите точку останова, щёлкнув правой кнопкой мыши и выбрав Remove (Удалить).
- …и так далее.
Щелчок правой кнопкой мыши по номеру строки позволяет создать условную точку останова. Она сработает только в тот момент, когда выражение, которое вы должны указать при создании такой точки, истинно.
Это удобно, когда нам нужно остановиться только для при определённом значении переменной или для определённых параметров функции.
18 Answers 18
One possible cause, it that you've enabled the "pause on exceptions" (the little stop-sign shaped icon with the pause (||) symbol within in the lower left of the window). Try clicking that back to the off/grey state (not red nor blue states) and reload the page.
Pausing on exceptions is neither a problem (@Luja) nor an issue (@Bosworth99) or something to be frustrated about (@dminer). It is a very helpful feature in debugging. It only takes a couple of hours (or less depending on your experience) to view all the options in the devTools UI and get comfortable with them. Please invest this time! It will help you immensely in your day-to-day debugging routine.
@CodeVortex Just because something is useful, that doesn't stop it being problematic if it is doing something you don't want right now and you don't know how to stop it.
In my case, I had the Any XHR flag set true on the XHR Breakpoints settings, accessible over the Sources tab within Chrome's dev tools.
Uncheck it for Chrome to work normally again.
This can also cause the issue
Break Point icon at top right should be blue like this
Should not grey like this
This is misleading as it disables stopping at any breakpoints, not the one at pageload. So this prevents also the breakpoints you want. The actual issue is not the button at the top right, but the checked "Any XHR" box at the bottom left.
This is good when you need to access the Debug window while being able to select something on the page, but the page gets locked by the script.
If you navigate to Sources you can see the pause button at the bottom of the DevTools. Basically there are 3 possible pause option in DevTools while debugging js file,
Don't pause on exceptions() :
The pause button will be in grey colour as if "Don't pause on exceptions" is active.
Pause on all exceptions() :
The pause button will be in blue colour as if "Pause on all exceptions" is active.
Pause on uncaught exceptions() :
The pause button will be in purple colour as if "Pause on uncaught exceptions" is active.
In your case, if you don't want to pause, select Don't pause on exceptions. To select, toggle the pause button till it become grey.
В сети полно обзоров Chrome DevTools, которые демонстрируют многочисленные возможности этого прекрасного инструмента. DevTools настолько большие, что познать их полностью, как мне кажется, уже почти невозможно.
В этой заметке я бы хотел остановиться на различных нюансах, полезных при отладке. Какие-то из них я почерпнул в сети (например в комментариях на Хабре), до каких-то додумался сам. Надеюсь вы найдёте для себя что-нибудь полезное.
Все горячие клавиши в статье будут даны для linux/windows.
BreakPoint-ы и PrettyPrint
Минифицированный код можно отформатировать так, чтобы с ним можно было работать:
Но очень часто даже после этого с ним невозможно работать. BreakPoint-ы ставятся куда попало (куда не кликай он появляется либо вначале файла, либо в его конце). Отладка просто сходит с ума (к примеру всегда указывает на первую строку файла).
Открыть этот локальный файл в редакторе
Отформатировать код файла (например Prettier-ом)
Сохранить (да, даже если это сторонняя библиотека)
Убедиться что пересборка webpack\rollup\whatever учла это изменение
Теперь вам не нужен DevTools-ий pretty print. Можно debug-ить напрямую.
HI-DPI
Что делать, если у вас обычный монитор, а клиенты жалуются на мыло на мобильных устройствах\retina экране? Для начала активируйте нужный DPR режим:
Теперь браузер имитирует HI-DPI. И всё стало таким угловатым (нюансы сглаживания при resize). Но как проверить настоящую картинку?
Открываем палитру команд ( Ctrl+P )
Ищем: capture area screnshoot
Выделяем мышью нужную область экрана, сохраняем в файл
Открываем файл и наслаждаемся огромной картинкой. Смотрим правда ли она "мыльная"?
Обычными системными скриншотами, разумеется, этого не достичь. Полагаю этот же рецепт работает и в обратную сторону (имитация 1х экрана).
Деактивация breakpoint-а
Небольшой нюанс, о котором знают не все. Поэтому я решил добавить его в подборку. Дело в том что breakpoint-ы можно не только добавлять и удалять, но и деактивировать. Для этого у вас есть три способа:
Вот эти галочки справа:
Вот это контекстное меню:
Просто Shift + LeftClick по панели breakpoint-а:
Управление интервалами выполнения кода
Поставив брейкпоинт, ми приостанавливаем исполнение функции на нем. Поэтому нам нужно будет продолжить построчное выполнение кода, чтобы изучить изменения нашей переменной.
В верхнем левом углу панели JavaScript Debugging находятся основные команды прогонки брейкпоинтов:
Первая кнопка, Resume script execution () продолжит выполнение кода до конца или до следующего брейкпоинта.
Давайте введем hello world в поле ввода. В строку добавится data = “hello world”. Теперь давайте кликнем на кнопку Step over next function call ().
Выбранная строка с брейкпоинтом будет выполнена и дебаггер выберет следующую. Откройте вкладку Scope чтобы посмотреть значение переменной data. Оно изменилось на “hello world”, которое мы ввели ранее и просто показывает значение нашей переменной на конкретной строке кода. Кликните Step over next function call еще раз чтобы выполнить выбранный метод и перейти на следующую строку.
Если обновить страницу, значение переменной out также обновится в DOM элементе. Чтобы посмотреть значение переменной, можно кликнуть на Expand () слева от нее. Если же еще раз кликнуть Step over next function call, то текст “hello world” еще раз добавится в dataSpan.
Команда debugger
Выполнение кода можно также приостановить с помощью команды debugger прямо изнутри самого кода:
Такая команда сработает только если открыты инструменты разработки, иначе браузер ее проигнорирует.
Пошаговое выполнение скрипта
А теперь давайте пошагаем по нашему скрипту.
Для этого есть кнопки в верхней части правой панели. Давайте рассмотрим их.
– «Resume»: продолжить выполнение, быстрая клавиша F8 .
Возобновляет выполнение кода. Если больше нет точек останова, то выполнение просто продолжается, без контроля отладчиком.
Вот, что мы увидим, кликнув на неё:
Выполнение кода возобновилось, дошло до другой точки останова внутри say() , и отладчик снова приостановил выполнение. Обратите внимание на пункт «Call stack» справа: в списке появился ещё один вызов. Сейчас мы внутри say() .
– «Step»: выполнить следующую команду, быстрая клавиша F9 .
Выполняет следующую инструкцию. Если мы нажмём на неё сейчас, появится alert .
Нажатие на эту кнопку снова и снова приведёт к пошаговому выполнению всех инструкций скрипта одного за другим.
– «Step over»: выполнить следующую команду, но не заходя внутрь функции, быстрая клавиша F10 .
Работает аналогично предыдущей команде «Step», но ведёт себя по-другому, если следующая инструкция является вызовом функции (имеется ввиду: не встроенная, как alert , а объявленная нами функция).
Если сравнить, то команда «Step» переходит во вложенный вызов функцию и приостанавливает выполнение в первой строке, в то время как «Step over» выполняет вызов вложенной функции незаметно для нас, пропуская её внутренний код.
Затем выполнение приостанавливается сразу после вызова функции.
Это хорошо, если нам не интересно видеть, что происходит внутри вызова функции.
– «Step into», быстрая клавиша F11 .
Это похоже на «Step», но ведёт себя по-другому в случае асинхронных вызовов функций. Если вы только начинаете изучать JavaScript, то можете не обращать внимания на разницу, так как у нас ещё нет асинхронных вызовов.
На будущее просто помните, что команда «Step» игнорирует асинхронные действия, такие как setTimeout (вызов функции по расписанию), которые выполняются позже. «Step into» входит в их код, ожидая их, если это необходимо. См. DevTools manual для получения более подробной информации.
– «Step out»: продолжить выполнение до завершения текущей функции, быстрая клавиша Shift + F11 .
Продолжает выполнение и останавливает его в самой последней строке текущей функции. Это удобно, когда мы случайно вошли во вложенный вызов, используя , но это нас не интересует, и мы хотим продолжить его до конца как можно скорее.
– активировать/деактивировать все точки останова(breakpoints).
Эта кнопка не влияет на выполнение кода, она лишь позволяет массово включить/отключить точки останова.
– включить/отключить автоматическую паузу в случае ошибки.
При включении, если открыты инструменты разработчика, ошибка при выполнении скрипта автоматически приостанавливает его. Затем мы можем проанализировать переменные в отладчике, чтобы понять, что пошло не так. Поэтому, если наш скрипт умирает с ошибкой, мы можем открыть отладчик, включить эту опцию и перезагрузить страницу, чтобы увидеть, где он умирает и каков контекст в этот момент.
Щелчок правой кнопкой мыши по строке кода открывает контекстное меню с отличной опцией под названием «Continue to here» («продолжить до этого места»).
Это удобно, когда мы хотим перейти на несколько шагов вперёд к строке, но лень устанавливать точку останова (breakpoint).
Race Condition
Что делать, если у вас есть сложная многостадийная асинхронная логика и с ней что-то не так. Например у вас race condition. Как проще всего воссоздать условия для его обнаружения? Я думаю, тут есть множество рецептов. Здесь я остановлюсь только на одном из них. В network вкладке есть такой dropdown:
Наверняка многие из вас им уже пользовались. Offline режим позволяет отловить ошибки при проблемах с сетью. Slow 3G проследить как быстро грузится ваш сайт при медленном интернете. Но обратите также внимание на секцию "Custom". Это заданные вручную режимы. Просто нажмите "Add" (внизу списка), чтобы добавить свой.
Какие режимы использую я?
Never: максимальная задержка. Просто выставите огромное число. Например сутки. Теперь любой запрос повисает до тех пор, пока вы не выключите этот режим. Запросы не "умирают", а именно повисают. Это даёт вам неограниченное время для отладки какой-нибудь промежуточной стадии вашей зубодробительной логики.
2\5\30sec latency: просто большая задержка. Актуальна когда вы отлаживаете "плавающий" баг. То он есть, то его нет. Или, скажем, когда вам нужно успеть сделать какое-нибудь быстрое действие мышью между двумя запросами. Или более пристально проследить что происходит, как бы в режиме slow-mo.
Читайте также: