firefox выполнить скрипт на странице

Команды для работы с JavaScript-консолью в браузерах и повышение производительности труда программиста

Если вы занимаетесь веб-программированием, это значит, что вам не надо рассказывать о том, насколько в вашей работе важна отладка. Нередко для записи данных в логи, для их форматирования или вывода на экран используют внешние библиотеки, не учитывая при этом того факта, что в распоряжении программистов имеются JavaScript-команды для работы с консолями, которые встроены в браузеры. И обладают эти консоли гораздо более серьёзными возможностями, чем может показаться на первый взгляд.

Что такое консоль?

Консоль JavaScript — это механизм, интегрированный в современные браузеры, который поддерживает встроенные инструменты разработки в интерфейсе, напоминающем командную строку. С использованием консоли разработчик может делать следующее:

Методы console.log, console.error, console.warn и console.info

Использование различных команд для вывода данных в консоль

Метод console.group

В консоль, после выполнения этого фрагмента кода, попадёт следующее.

Группировка данных в консоли с помощью метода console.group()

Метод console.table

То, что получилось, и выглядит отлично, и способно облегчить отладку.

Табличное оформление выводимых данных с помощью console.table()

Методы console.count, console.time и console.timeEnd

А вот как выглядит результат работы этого кода в консоли.

Использование методов console.count(), console.time() и console.timeEnd()

Методы console.trace и console.assert

Несложно заметить, что вывод, генерируемый этим фрагментом кода, выглядит так же, как нечто подобное выглядело бы в React (или в любой другой библиотеке), когда фреймворк сообщает о возникновении исключения.

Результат использования команд console.assert() и console.trace()

Команды для работы с консолью и продакшн-код

Команды для работы с консолью нужны на этапе разработки и отладки приложений. Это значит, что когда придёт время выпуска продукта, эти команды придётся из кода удалить. Об этом можно просто забыть и, через некоторое время после сборки продакшн-версии проекта, заметить, что программа пишет что-то в консоль тогда, когда в этом нет никакой необходимости. Не стоит нагружать компьютеры ненужной работой, пусть и такой, казалось бы, незначительной, как вывод данных в консоль. В то же время, учитывая то, что команды для работы с консолью могут пригодиться в ходе доработки приложения, лучше всего не удалять их из исходного кода программы насовсем, а убирать их лишь из её продакшн-версии. Тут нам на помощь придут средства для сборки проектов. Так, я постоянно пользуюсь Webpack, и на работе, и в собственных проектах. Этот инструмент позволяет удалять все ненужные команды по работе с консолью (он способен отличить их от других команд) из продакшн-сборок с использованием uglifyjs-webpack-plugin.

Эта конфигурация очень проста, но она облегчает повседневную работу программиста и избавляет от проблемы забытых команд по работе с консолью.

Итоги

В этом материале мы рассказали о некоторых полезных командах для работы с консолью. Они позволяют, с помощью инструментов, являющихся частью современных браузеров, решать множество задач, которые сопутствуют разработке и отладке клиентских JavaScript-приложений.

Уважаемые читатели! Какие команды для работы с JavaScript-консолью вы используете?

Источник

Погружение в темные воды загрузки скриптов

Введение

В этой статье я хочу научить вас как загружать в браузер JavaScript и выполнять его.

Нет, подождите, вернитесь! Я знаю, что это звучит заурядно и просто, но помните, что это происходит в браузере, где теоретически простое превращается в набор причуд, определенных наследственностью. Знание этих причуд поможет вам выбрать самый быстрый, наименее разрушительный способ загрузки скриптов. Если вы спешите, то можете перейти сразу к краткому справочнику в конце статьи.

Для затравки, вот как спецификация определяет различные способы загрузки и выполнения скриптов:

Как и все спецификации WHATWG, на первый взгляд данная спецификация выглядит как последствия кассетной бомбы на фабрике Scrabble. Но, прочитав ее на 5 раз и вытерев кровь из своих глаз, начинаешь находить ее довольно интересной:

Мое первое подключение скрипта

Ах, блаженная простота. В данном случае браузер скачает оба скрипта параллельно и выполнит их как можно скорее, сохраняя заданный порядок. «2.js» не будет выполняться пока не выполнится «1.js» (или не сможет этого сделать), «1.js» не выполнится пока не выполнится предыдущий скрипт или стиль, и т.д. и т.п.

Вот почему гуру и специалисты производительности советуют размещать элементы script в конце документа, потому что это блокирует меньше всего контента. К сожалению, это означает, что ваш скрипт не будет увиден браузером до того времени, как будет скачен весь HTML, а также уже запущена загрузка CSS, картинок и iframe-ов. Современные браузеры достаточно умны, чтобы отдавать приоритет JavaScript над визуальной частью, но мы можем сделать лучше.

Спасибо, IE! (нет, я это без сарказма)

WHATWG сделали это поведение явным, объявив, что «defer» не будет иметь никакого эффекта на скрипты, которые были добавлены динамически или не имеют «src». В противном случае, скрипты с «defer» должны запускаться в заданном порядке после того, как документ был распарсен.

Спасибо, IE! (ну ладно, теперь с сарказмом)

Одно дали — другое отобрали. К сожалению, есть неприятный баг в IE4-9, который может спровоцировать выполнение скриптов в неверном порядке. Вот что происходит:

Допустим, что на странице есть параграф, ожидаемый порядок логов — [1, 2, 3], но в IE9 и ниже результат будет [1, 3, 2]. Некоторые операции DOM вынуждают IE приостановить выполнение текущего скрипта и перед продолжением начать выполнение других скриптов в очереди.

HTML5 спешит на помощь

HTML5 дал нам новый атрибут «async», который предполагает, что вы также не используете document.write, но при этом не ожидает окончания парсинга документа. Браузер параллельно скачает оба скрипта и выполнит их как можно скорее.

К сожалению, так как они постараются выполниться максимально скоро, «2.js» может выполниться раньше «1.js». Это отлично, если они не зависят друг от друга. Например, если «1.js» — это отслеживающий скрипт, не имеющий ничего общего с «2.js». Но если «1.js» — это CDN-копия jQuery, от которой зависит «2.js», то ваша страница будет устлана ошибками, как после кассетной бомбы в… я не знаю… здесь я ничего не придумал.

Я знаю, нам нужна JavaScript-библиотека!

В Святом Граале содержится набор скриптов, загружающихся сразу, без блокирования отрисовки страницы и выполняющихся максимально скоро, в том порядке, в котором мы их добавили. К сожалению, HTML ненавидит вас и не позволит вам этого сделать.

Проблема была решена с помощью JavaScript на разный манер. Некоторые способы требовали от вас вносить изменения в JavaScript, оборачивать всё в callback, который библиотека вызовет в правильном порядке (например, RequireJS). Другие использовали XHR для параллельной загрузки, а затем eval() в нужном порядке, который не работает для скриптов на другом домене, если там нет заголовка CORS и поддержки его в браузере. Некоторые использовали даже супер-магические хаки, как это было сделано в последнем LabJS.

Хаки всяческим образом обманывали браузер, чтобы тот загружал ресурс, вызывая при этом событие по окончанию загрузки, но не начинал его выполнение. В LabJS скрипт сначала добавлялся с некорректным mime-типом, например
Скрипты, которые созданы и добавлены динамически, асинхронные по-умолчанию, они не блокируют отрисовку и выполняются сразу после загрузки, что означает, что они могут появиться в неверном порядке. Однако мы можем явно пометить их неасинхронными:

Это даст нашим скриптам сочетание с поведением, которое не может быть достигнуто чистым HTML. Явно заданные неасинхронными, скрипты добавляются в очередь на выполнение, такую же, как они попадали в нашем первом примере на чистом HTML. Однако, создаваемые динамически, они будут выполняться вне парсинга документа, что не будет блокировать отрисовку, пока они будут загружаться (не путайте неасинхронную загрузку скрипта с синхронным XHR, что никогда не является хорошей вещью).

Скрипт выше должен быть встроен в head страниц, начиная очередь загрузок как можно раньше, без нарушения постепенной отрисовки, и начиная выполнять как можно раньше, в заданном вами порядке. «2.js» может свободно загружаться до «1.js», но он не будет выполнен до тех пор, пока «1.js» успешно не скачается и выполнится или не сможет сделать что-либо из этого. Ура! Асинхронная загрузка, но выполнение по порядку!

Загрузка скриптов этим методом поддерживается везде, где поддерживается атрибут async, за исключением Safari 5.0 (на 5.1 все хорошо). Кроме того все версии Firefox и Opera, которые не поддерживают атрибут async, все равно выполняют динамически-добавленные скрипты в правильном порядке.

Это самый быстрый способ загружать скрипты, так? Так?

Ну если вы динамически решаете какие скрипты загружать — да, иначе — возможно, что нет. В примере выше браузер должен распарсить и загрузить скрипт, чтобы определить какие скрипты загружать. Это скрывает ваши скрипты от сканеров предзагрузки. Браузеры используют эти сканеры для обнаружения ресурсов, которые вы скорее всего посетите следующими и для обнаружения ресурсов страницы пока парсер заблокирован другим ресурсом.

Мы можем добавить обнаружаемость обратно, поместив это в head документа:

Эта статья меня удручает

Ситуация удручающая и вы должны чувствовать себя удрученным. Еще нет декларативного способа без повторений для загрузки скриптов быстро и асинхронно, в то же время управляя порядком выполнения.

С появлением HTTP2/SPDY вы сможете уменьшить накладные ресурсы до точки, где доставка скриптов в маленьких самостоятельно-кэшированных файлах будет самым быстрым способом. Только представьте:

Каждый enhancement-скрипт имеет дело с конкретным компонентом страницы, но требует вспомогательные функции в dependencies.js. В идеале, мы хотим загрузить все асинхронно, затем выполнить enhancement-скрипт как можно раньше, в любом порядке, но после dependencies.js. Это прогрессивное прогрессивное улучшение!

К сожалению, нет декларативного способа для того, чтобы достичь этого, только если модифицировать сами скрипты для отслеживания состояния загрузки dependencies.js. Даже async=false не решит эту проблему, потому что выполнение enhancement-10.js будет заблокировано на 1-9. По факту, есть только один браузер, в котором можно достичь этого без хаков…

У IE есть идея!

IE грузит скрипты не так, как другие браузеры.

IE начинает закачивать «whatever.js» сейчас, другие же браузеры не начнут загрузку до того момента, пока скрипт не будет добавлен к документу. У IE также есть событие «readystatechange» и свойство «readystate», которые сообщают о процессе загрузки. Это на самом деле очень полезно, потому что позволяет нам управлять загрузкой и выполнением скриптов независимо друг от друга.

Хватит! Как я должен загружать скрипты?

Ладно, ладно. Если вы хотите загружать скрипты способом, который не блокирует отрисовку, не требует дублирования и имеет прекрасную поддержку браузеров, то я советую вот этот:

Именно этот. В конце элемента body. Да, быть веб-разработчиком — это как быть царем Сизифом (бум! 100 хипстерских очков за упоминание греческой мифологии!). Ограничения HTML и браузеров не позволяют нам сделать сильно лучше.

Я надеюсь, что модули JavaScript нас спасут, предоставив декларативный неблокирующий способ загружать скрипты и иметь контроль над порядком их запуска, даже если это потребует написание скриптов в виде модулей.

Иуу, должно быть что-то получше, что мы можем использовать сейчас?

Ладно, ради бонусных очков, если вы всерьез думаете о производительности и не боитесь сложности и дублирования, то можете объединить несколько рассмотренных трюков.

Во-первых, мы добавим объявление subresource для предзагрузчиков:

Спецификация говорит: Скачивай вместе, выполняй по порядку после любого ожидающего CSS, блокируй отрисовку, пока не закончишь
Браузер отвечает: Да, сэр!

Defer

Спецификация говорит: Скачивай вместе, выполняй по порядку до DOMContentLoaded. Игнорируй «defer» для скриптов без «src».
IE

Источник

Встраиваемый скрипт

Фоновые скрипты имеют доступ ко всем методам WebExtension JavaScript APIs, но они не имеют доступа к контенту отдельных веб-страниц. Так что если вашему расширению необходимо взаимодействие с контентом веб-страницы, вам нужен встраиваемый скрипт.

Точно так же, как скрипты загружаемые веб-страницами, встраиваемый скрипт может читать и изменять контент веб-страницы, используя DOM API.

Встраиваемые скрипты имеют доступ только к небольшому подмножеству методов WebExtension API, но они могут взаимодействовать с фоновыми скриптами, используя систему передачи сообщений, таким образом опосредовано имея доступ ко всему WebExtension API.

Обратите внимание, что встраивание скриптов блокируется на следующих доменах:

Если вы попытаетесь встроить скрипт на страницы, находящиеся на вышеперечисленных доменах, у вас ничего не выйдет, и веб-страница сделает запись о CSP ошибке.

По причине того, что список запрещённых доменов включает в себя addons.mozilla.org, пользователи, которые попытаются испытать ваше расширение прямо на странице загрузки, могут посчитать, что расширение не работает! В связи с этим вы могли бы предоставить им соответствующее предупреждение или onboarding page чтобы немедленно переадресовать их с addons.mozilla.org.

Значения, определённые в глобальной области видимости встраиваемого скрипта с помощью var foo или window.foo = «bar» могут исчезать по причине бага 1408996.

Загрузка встраиваемого скрипта

Загрузка встраиваемых скриптов на веб-страницу происходит следующими тремя способами:

Существует только одна глобальная область видимости для одного фрейма, для одного расширения. Это означает, что значения из одного встраиваемого скрипта могут быть доступны для другого встраиваемого скрипта, не зависимо от того, как встраиваемый скрипт был загружен на страницу.

Используя методы (1) и (2), вы можете загружать скрипты на страницы, чьи URL могут быть представлены, используя шаблон совпадения.

Используя метод (3), вы к тому же можете загружать скрипты на страницы вашего расширения, но вы не можете загружать скрипты на привилегированные страницы браузеры (например «about:debugging» или «about:addons»).

Условия работы встраиваемого скрипта

Доступ к DOM

Встраиваемые скрипты имеют доступ и могут изменять DOM на веб-странице, так же как и обычные скрипты. Так же они могут видеть любые изменения сделанные с DOM страничными скриптами.

При этом, встраиваемые скрипты имеют «чистое DOM представление». Это значит:

В Firefox это поведение называется Xray vision (en-US).

Например, рассмотрите эту веб-страницу:

Скрипт «page-script.js» делает следующее:

Теперь расширение загружает встраиваемый скрипт на страницу:

Те же самые правила применяются и наоборот: страничный скрипт не может видеть JavaScript свойств, добавленных встраиваемым скриптом.

Это означает, что встраиваемый скрипт может полагаться на то, что DOM свойства всегда будут вести себя предсказуемо, и не беспокоиться о том, что его переменные будут иметь конфликт с переменными из страничного скрипта.

Одно из последствий такого поведения состоит в том, что встраиваемый скрипт не будет иметь доступ к JavaScript библиотекам, загруженным страничным скриптом. Например, если веб-страница загружает jQuery, встраиваемый скрипт не сможет увидеть эту библиотеку.

Если встраиваемому скрипту необходимо использовать какую-либо JavaScript библиотеку, тогда эта библиотека должна быть загружена, тем же способом, как и встраиваемый скрипт вместе с ним:

Примечание: Firefox предоставляет некоторое API, позволяющее встраиваемому скрипту иметь доступ к JavaScript объектам, созданным страничным скриптом, и предоставлять свои собственные JavaScript объекты страничному скрипту.

Доступные WebExtension API

В дополнение стандартному DOM API, встраиваемый скрипт может использовать следующие методы WebExtension APIs:

Работа с XHR и Fetch

Встраиваемые скрипты могут делать запросы используя window.XMLHttpRequest и window.fetch() API.

Встраиваемый скрипт имеет точно такие же кросс-доменные привилегии, как и всё остальное расширение: так что если расширение запросило кросс-доменный доступ на какой-либо домен используя permissions ключ в manifest.json, тогда его встраиваемый скрипт тоже будет иметь доступ к этому домену.

Взаимодействие с фоновыми скриптами

Хотя встраиваемые скрипты не могут напрямую использовать большинство методов из WebExtension APIs, они могут взаимодействовать с фоновыми скриптами расширения, используя систему сообщений, и таким образом могут опосредованно иметь доступ к тем же самым API, что и фоновые скрипты.

Существует два способа общения между фоновым и встраиваемым скриптами: вы можете посылать одиночные сообщения, ожидая необязательного ответа, или вы можете установить долгосрочное соединение на двух сторонах и использовать это соединение для обмена сообщениями.

Одиночные сообщения

Для отправки одиночного сообщения и ожидания необязательного ответа, вы можете использовать следующее API:

Например, представьте встраиваемый скрипт, который обрабатывает нажатие левой кнопки мыши на веб-странице.

Если нажатие было произведено по ссылке, встраиваемый скрипт отправляет сообщение фоновому скрипту со значение URL в ссылке:

Фоновый скрипт ожидает эти сообщения и, при их получении, отображает уведомления, используя notifications (en-US) API:

(Этот пример кода частично взят из notify-link-clicks-i18n примера на GitHub.)

Обмен сообщениями через постоянное соединение

Отправка одиночных сообщений может стать довольно обременительной, если вы пересылаете много сообщений между встраиваемым и фоновым скриптами. Альтернативное решение в этой ситуации будет установить постоянное соединение между двумя скриптами, и использовать его для обмена сообщениями.

Каждая из сторон имеет runtime.Port (en-US) объект, который они могут использовать для обмена сообщениями.

Для создания постоянного соединения:

Результатом вызова этих методов будет возвращение runtime.Port (en-US) объекта.

Как только обе стороны имеют порт, они могут:

Например, сразу после загрузки, нижерасположенный встраиваемый скрипт:

Соответствующий фоновый скрипт:

Несколько встраиваемых скриптов

Если вы имеете несколько встраиваемых скриптов, с которыми вы обращаетесь в одно и то же время, вы бы могли сохранять каждое соединение в массиве.

Взаимодействие с веб-страницей

Хотя по умолчанию встраиваемые скрипты не имеют доступ к объектам, которые созданы страничными скриптами, они могут взаимодействовать со страничными скриптами, используя window.postMessage и window.addEventListener API.

Для просмотра законченного и полностью рабочего примера, посетите эту страницу на GitHub и следуйте инструкциям.

Как простейший пример, представим встраиваемый скрипт, который получает сообщение от веб-страницы и делает что-то вроде этого:

Теперь страничный скрипт может запускать любой код со всеми привилегиями встраиваемого скрипта.

Использование eval() во встраиваемых скриптах

В Chrome, eval() всегда выполняет код в контексте встраиваемого скрипта, а не в контексте веб-страницы.

Например, рассмотрите этот встраиваемый скрипт:

Получая сообщение, страничный скрипт записывает те же самые переменные:

В Chrome, в консоли будут записаны следующие строки:

В Firefox, будут записаны следующие строки:

Будьте очень осторожны, запуская код в контексте страничного скрипта. Окружение страничного скрипта может контролироваться потенциально зловредным веб-страницей, которая может переопределить объекты, с которыми вы взаимодействуете, так что их поведение станет совершенно непредсказуемым:

Источник

Userscripts. Углубляемся

Как упоминалось в предыдущей статье, юзерскрипты поддерживаются всеми современными браузерами. И даже кое-как поддерживаются в IE7 и выше.

Пару слов о движках

Качество поддержки юзерскриптов находится на разном уровне в разных браузерах. Лучше всего поддержка юзерскриптов выполнена в браузерах Firefox и Chrome.
Эти браузеры предоставляют более менее дружелюбные интерфейсы для управления юзерскриптами.

Самые жесткие ограничения на юзерскрипты накладывает Chrome. Но почти все эти ограничения обходятся упаковыванием скрипта в простое расширение. Подробности этого процесса мы обсудим в следующей статье.

Теперь поговорим подробнее о поддержке юзерскриптов в отдельных браузерах.

Поддержка в Firefox

Mozilla Firefox поддерживает юзерскрипты после установки расширения GreaseMonkey (в русском сленге — обезъяна) или Scriptish.
После установки расширений фаерфокс получает поистине мощную поддержку юзерскриптов.
Рассматриваемая далее информация применима в первую очередь к GreaseMonkey (это расширение было первым).

Исторически, все юзерскрипты писались под браузер Firefox именно из-за наличия удобного плагина.
Это обусловливает тот факт, что все браузеры, которые поддерживают юзерскрипты, дополнительно следуют основным правилам спецификации GreaseMonkey по разбору метаданных.
Это означает, что все скрипты, которые были написаны под GreaseMonkey, будут устанавливаться и запускаться в браузерах, поддерживающих юзерскрипты (с минимумом модификаций).

К сожалению, ни один браузер, кроме Firefox, не предоставляет GM API. Этот печальный факт заставляет использовать эмуляции GM API через расширения или дополнительные юзерскрипты.

В случае разработки юзерскрипта «с нуля», я считаю предпочтительным отказаться от эмуляции GM API и использовать «велосипеды» собственного производства. Это позволяет уменьшить число зависимостей юзерскрипта, что, в свою очередь, позволяет вести разработку в рамках концепции одного файла: модифицировать придётся всего один файл; пользователю нужен всего один файл для запуска юзерскрипта.

Концепция одного файла позволяет существенно уменьшить сложность поддержки и кроссбраузерной разработки юзерскриптов!

Поддержка в Chrome

Google Chrome поддерживает юзерскрипты нативно, т.е. не требует установки плагинов/расширений. Можно (иногда нужно) упаковать юзерскрипт в расширение.

Важно: фактически, расширение и юзерскрипт — разные понятия. И если подходить к вопросу строго, стоит говорить о разработке простых расширений под Chrome.
В случае, когда юзерскрипт требует нестандартного, «тяжелого» функционала, он требует упаковки в расширение.
Для упаковывания юзерскрипта в расширение нужно проделать дополнительные действия один раз. Вся последующая разработка будет вестись в рамках концепции одного файла.

Поддержка в Opera

Opera поддерживает юзерскрипты нативно, но не предоставляет сколь-нибудь дружелюбного пользовательского интерфейса для управления скриптами. Такой интерфейс доступен в расширении UJS Manager.

Поддержка в IE

IE7, IE8, IE9 поддерживают юзерскрипты при использовании плагина Trixie.
К тому же, имеется более продвинутый плагин IE7Pro. В IE7Pro помимо поддержки юзерскриптов имеется множество других бесполезных возможностей.

Важно: Если не отключать дополнительные «приблуды» в IE7Pro, то плагин может изрядно тормозить браузер, особенно на тяжёлых страницах.

Как видите, с запуском скриптов у IE дела обстоят паршиво. Остаётся радоваться, что такая возможность вообще имеется.

Важно: Оба плагина могут существовать в системе одновременно, не мешая друг другу.

Важно: Учитывая вышесказанное, я всегда предлагаю своим пользователям использовать Trixie.

Поддержка в Safari

К сожалению, мне не довелось поработать с данным браузером. Буду рад любым разъяснениям в комментариях!
Поговаривают, что для Safari нужны SIMBL и плагин GreaseKit.

Поддержка в Mobile Safari и прочих браузерах

В виду отсутствия поддержки юзерскриптов в менее популярных браузерах и мобильных браузерах, юзерскрипты придётся предоставлять в виде букмарклета.
Соотстветственно, метаданные в таком случае не нужны, а букмарклет придётся запускать руками после каждого рефреша.

На последок

Источник