Рубрика «postMessage»

Предыстория

Небольшое вступление для понимания “зачем мне это надо”. Так получилось, что организация, в которой я работаю, выпускает несколько продуктов, результатом работы одного из них является HTML документ. Продукты десктопные, и HTML документ приходится открывать в WEB-браузере с локального диска. Всё бы ничего, если бы не ограничения браузеров, которые работают на “движке” Chromium. В моём случае в “хроме” нельзя из одного iframe изменить src другого iframe. Вернее это ограничение можно обойти, если “хром” запустить с ключом: chrome.exe – allow-file-access-from-files. Но, к сожалению, это срабатывает только в том случае, если ни одной копии “хрома” не загружено. Всё это накладывает ограничения или, вернее, неудобства при работе с документами.
Читать полностью »

Реализации setImmediate: сообщения, мутация или обещания, что быстрее? - 1

Доброго времени суток, %username%! Маленькое исследование на тему «какой же способ поставить функцию/метод на обработку в очередь эффективнее» и, как результат, сравнительный тест, и итоговая реализация схожей с setImmediate функции. Этот метод нужен тем, кто хочет разбивать выполнение скрипта, чтобы тот не «подвешивал» браузер, что бывает полезно при огромном скрипте инициализации, разборе большого массива данных, построения сложной структуры не прибегая к WebWorkers.

Для понимания: setImmediate это метод объекта window, который должен вызвать функцию, переданную в неё, асинхронно, эдакий setTimeout(fn, 0), где 0 реально 0, а не минимум 4. Для nodejs-программистов это process.nextTick. Т.к. сам метод (setImmediate) имеет чёткий стандарт с ошибками и дополнительными параметрами, рассмотрим абстрактную задачу асинхронного выполнения переданной функции/метода как можно быстрее.

Исследования исключительно в рамках сценариев браузера, при чём основных, т.к. в работниках (workers) не совсем понятно зачем такое дробление, хотя если нужно, можно попробовать обещания и сообщения.

Итак, давайте узнаем, что же лучше подходит: postMessage, MutationObserver или Promise?
Читать полностью »

В отличие от расширений, букмарклеты хороши простотой и кроссбраузерностью. Конечно, они ограничены контекстом окна (содержимого страницы), но часто этого достаточно. А с возникновением механизма localStorage у них появился простой способ сохранять и запрашивать данные на стороне клиента.
Читать полностью »

Сегодня я хочу рассказать о том, как мы в своем проекте indexisto.com сделали дешевую китайскую подделку аналог инструмента Google Webmaster Marker. Напомню, что Marker это инструмент в кабинете Google Webmaster, который позволяет аннотировать ваши страницы Open Graph тегами. Для этого вы просто выделяете мышкой кусок текста на странице и указываете что это title, а это рейтинг. Ваша страница при этом грузиться в Iframe в кабинете вебмастера.

Доступ к контенту iFrame с другого домена

Теперь Google, встретив подобную страницу на вашем сайте, уже знает, что за контент на ней опубликован, и как его красиво распарсить в сущность (статью, товар, видео..)

Нам был нужен подобный функционал. Задача казалась несложной и исключительно клиентсайд. Однако на практике решение лежит на стыке клиентсайда и серверсайда («чистые» JS программисты могу ничего не знать про различные прокси серверы и очень долго подходить к снаряду). При этом я не нашел в интернетах статью которая описывала бы всю технологию от начала до конца. Также хочется сказать спасибо пользователю BeLove и нашим безопасникам за помощь.

Читать полностью »

Кроссдоменный postMessage или как браузеры поддерживают стандартыВо время прикручивания облачных хранилищ к скрипту для бэкапа, встала необходимость использовать OAuth 2 авторизацию, для использования с разными облачными API. В принципе с самой авторизацией никаких сложностей не возникло, но проблема возникла в немного неожиданном месте.

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

Но не тут-то было…
Читать полностью »

Нельзя просто так взять и обратиться к фоновой страницеВсё дело — в политике безопасности, аналогичной кроссдоменной. Обращение к страницам других табов или к фоновой странице расширения сознательно ограничено, потому что они считаются страницами других доменов, имеют запреты на прямой доступ к скриптовому окружению, аналогично чужим окнам и фреймам. Механизм сообщений «спасает» как при кроссдоменном доступе между фреймами, как и в доступе к страницам расширений (фоновая, настройки, попап, ...).

В расширении браузера Google Chrome (и Chromium) наиболее важна по функциям — фоновая страница. Она имеет специальный URL вида chrome-extension://ciegcibjokpkcklhgbpnmnikpkmkhbjk/, где длинное имя домена — случайное имя, создаваемое в недрах браузера, которым именуется также каталог расширения где-то в служебной папке ОС. Из контентного скрипта (аналогичного юзерскриптам, исполняемым на странице браузера) можно получить доступ к файлам и картинкам расширения. Но нельзя выполнить много функций, путь к которым лежит через фоновую страницу: устроить хранилище, относящееся к группе реальных доменных имён; хранить настройки расширения, общие для всего расширения. Нужно лишь добраться в Мордор к фоновой странице. Однако, нельзя просто так, по URL, это сделать.
Читать полностью »

В Хроме и Хромиуме уже 2.5 года существует баг отсутствия кроссдоменного доступа к другому фрейму из контекстного скрипта (юзерскрипта). То, что нормально работает в скрипте обычной страницы, например, межсайтовая передача данных с помощью postMessage и что без проблем работает в других браузерах, в Хроме иногда считается «ограничением безопасности», но на самом деле это обычный и признанный баг, отмеченный с 4-й версии.
Читать полностью »