разработка
Хочется материться
Submitted by antonglv on Sat, 12/13/2008 - 15:30.в FF3.1 мне уже нельзя пользоваться document.load'ом:
Warning: Cross site loading using document.load is no longer supported. Use XMLHttpRequest instead.
Source File: about:blank
Line: 0
собственно, сабж
Думы
Submitted by antonglv on Fri, 12/12/2008 - 14:57.Оказывается, уже который год не работает инициализация кнопок в диалоге настройки панелей инструментов.
Причина - на customizeToolbar.xul не "подшивается" overlay.css, в котором нужные -moz-binding'и.
Не помню, как такое могло случиться.
Кажется, был какой-то баг в Thunderbird с отображением кнопок.
Перенёс инструкции из overlay.css в custombuttons.css - ничего странного не наблюдаю.
То ли надо совсем избавиться от overlay.css, то ли прописать его как надо в chrome.manifest.
<script src="..."/>
Submitted by antonglv on Mon, 06/02/2008 - 08:47.(В продолжение предыдущей записи)
Скрипты, загружаемые из файла, кэшируются независимо от того, по какому протоколу они загружаются. Оверлеи не кэшируются, если они загружаются по протоколу, отличному от chrome:, а скрипты - кэшируются.
Засада
Submitted by antonglv on Sun, 05/25/2008 - 17:35.В продолжение предыдущей записи.
new Function ("}")
не возвращает ошибку. Хотя
(function () { } })
выдаст "missing ) in parenthetical". Из-за этого вся затея с загрузкой кодов кнопок через mozIJSSubScriptLoader становится неактуальной. Потому что есть кнопки, у которых в коде присутствуют закрывающие фигурные скобки без соответствующих открывающих. И с
new Function (... они работают. То есть, даже если вычислить подобную ошибку с помощью eval, работать эти кнопки всё равно уже не будут.
UPDATE. В FF3 это поведение исправлено,
new Function ("}") выдаёт ошибку. Вместе с тем, замысел более осуществимым не становится, так как в FF3 "починили" также и mozIJSSubScriptLoader - там он теперь загружает файлы только по протоколам chrome://, file:// и resource://. Хромовый протокол отпадает, так как кэширует данные. В любом случае, нужен собственный обработчик этих протоколов, который бы при запросах, не исходящих от расширения, передавал бы управления стандартным обработчикам. Модули (Components. utils. import) тоже кэшируются.
Разве что попробовать динамически подгружать оверлей, хотя, толку похоже от этого не случится.
Просто нет слов, что тут скажешь...
Хоть бы не сломали возможность загрузки оверлеев по нужным протоколам...
UPDATE: Да, вот разве что попробовать направить протокол resource на свой протокол. Но эта возможность только в FF3, так что единым кодом не обойтись. Один километр кода - для FF2 с вычислением ошибки через
eval и удалением последнего символа в случае чего, второй - для FF3, вычисляющий ошибку через Function и корректирующий resource:// в custombutton:// хитрым хаком.
UPDATE: А, ну да, конечно, ещё можно сделать пару каталогов в подкаталоге расширения в профиле, "custombuttons/init" и "custombuttons/code", создавать там js файлы и грузить код по протоколу
file://.
UPDATE: Ещё один вариант: подгружать оверлей, в котором будет
<script src="custombutton://..."/> ? Надо попробовать.
Идея (продолжение)
Submitted by antonglv on Sat, 05/24/2008 - 19:29.Отслеживание ошибок в коде кнопок (Идея) реализовано и работает. Кроме случаев вида
this. onclick = function (event) { bla (); };
Если
bla не определено, в консоли появляется не поддельный адрес кнопки, а адрес js-файла расширения.
Для исправления этого недочёта хочу попробовать изменить способ выполнения кода кнопки. Мысль такая: код кнопки будет загружаться с помощью mozIJSSubScriptLoader по поддельному протоколу в контексте функции, ответственной за выполнение кода кнопки.
Провёл эксперимент с загрузкой локального js-файла из init-раздела кнопки, результат положительный. Теперь буду думать, как реализовать это в расширении. По меньшей мере надо будет изменить код, отслеживающий ошибки при вызове исполняющей функции, а также придумать, как передать код кнопки обработчику протокола. Возможно, будут проблемы с контекстом выполнения; не хотелось бы - если такие появятся, вся задумка окажется несостоятельной.
