Добрый день

Написал плагин для FF на С++ - просто скатал с подходящего в GeckoPluginSDK-samples, реализовал все что мне было надо.
Таким образом, плагин у меня состоит из:
dll
xpt (там еще есть scriptable интерфейс)

Я не очень знаком с тем, как правильно устанавливать такие плагины - поэтому просто копировал файлы в ..\Mozilla Firefox\plugins и мне этого хватало.

Но встал вопрос с версионированием - как сделать так, чтобы при наличии новой версии плагина FF сам делал update этого плагина? Наверное пришло время сделать установку плагина по человечески.

Заранее благодарен за помощь.

Лучше написать расширение. Посмотрите CacheFixer: там воды вроде нет.

1) каталог "defaults" можно выкинуть, если не нужно задавать дефолные пользовательские настройки.
2) dll, xpt -- нужно положить в каталог "components".

Сам же update происходит очень просто: браузер идёт по url, указанному в install.rdf (<em:updateURL/>), смотрит, есть ли более свежая версия, и, если есть, то качает расширение с указанного адреса. Расширение обновляется полностью, т.е. с компонентами включительно.

Какие детали интересуют -- спрашивайте.

Спасибо, почитаю ссылку.

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

Ага, слово "плагин" мимо ушей пролетело.

Если там именно плагин нужен, а не компонента...
Как я понимаю, во время работы браузера плагины ставятся в read-only и просто перезаписать dll при запущенном браузере не получится... М.б. там подойдут какие-нибудь фичи в духе "Firefox extension update failure" (там правда про компоненты и баг, из которого растут ноги, уже исправлен).

Точно, просто переписать dll плагина поверх или удалить его не получится. Была надежда что есть стандартный способ, когда FF сам это сделает, но видимо нет. Попробую действительно перейти на extension, прежде чем использовать всякие нестандартные решения

Правда, была надежда на свойство плагина: pluginspage=url - эсли плагин не установлен, FF предлагает его взять оттуда, я думал, что может он и версии будет апдейтить таким образом - только не знаю как все это дело туда положить. Описания rdf для extension есть, а для плагинов не видел - может то же самое?

Я сам с плагинами не сталкивался, не знаю; ковырять надо.

Anyway, а в чём смысл плагина, если не секрет?

Да не секрет, это автоматический редирект на одну программку - Download Manager, если пользователь зашел на эту страницу и соблюдаются некоторые условия - добавляется прописанная закачка, а если не соблюдаются, тогда нужно сначала поставить этот Download Manager и настроить. Как по мне - можно было и XPCOM накатать, смысл плагина-то - выводить что-то на экран, но люди захотели plugin "потому что его просто вставил на страницу, задал свойства и никакого JS не надо". Вот така фигня, а потом оказалось что JS все равно нужен

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

В общем, установить плагин можно (условно) тремя способами:

1) exe -- помимо троянов записывает в каталог plugins и, при необходимости, в реестр своё добро;
2) xpi -- в скачанных мной двух плагинах обнаружен стандартный install.js, понимаемый как Mozilla, так и Firefox. Результат тот же: или простое копирование файлов (fastbid2.xpi, 236kb), или копирование + реестр (VirtoolsWebPlayer.xpi, 61kb);
3) копирование "ручками" -- ну, это понятно.

Идём далее...

Во всех этих случаях авторы не стремились к автоматическому обновлению, которое бы задействовало "родные" механизмы браузера. Такое обновление возможно лишь для Firefox при условии, что плагин будет представлять из себя расширение, где в install.rdf задаётся адрес, по которому браузер будет узнавать об этих самых обновлениях.

Т.о. наиболее оптимален (с моей точки зрения, могу ошибаться, имею право :]) такой вариант: пишется расширение, в набор которой входит install.js, install.rdf, components/plugin.dll, components/plugin.xpt и components/checker.js.

install.js -- для Mozilla (про автообновления пользователям этого браузера придётся забыть);
install.rdf -- для Firefox;
components/plugin.dll, components/plugin.xpt -- собственно плагин;
components/checker.js -- компонента, проверяющая "соответствие".

Вот на тему проверки этого "соответствия" можно будет подумать чуть больше.

Один из вариантов: при каждом старте браузера checker.js будет смотреть наличие plugin.dll/plugin.xpt в каталоге components/ расширения. Если таковые будут обнаружены, то перемещает их в каталог plugins/ браузера. В следующий раз plugin.dll/plugin.xpt появятся в каталоге компонент расширения только после обновления самого расширения. Появились? ok, повторяем процедуру перемещения.

Я не думаю, что возникнут сложности с реализацией.

Два минуса:
1) не-Firefox пользователи в пролёте;
2) необходимость в дополнительной перезагрузке браузера после установки/обновления расширения.

Идём далее...

Дурной вопрос, просто "от незнания": имеет ли плагин доступ к атрибуту "pluginspage" обрабатываемого в текущий момент объекта? Если имеет, то
pluginspage можно задавать в виде url?v=1.2, где "v" -- какая-то версия. Внутри плагина при обработке объекта это значение парсится и, если плагин написан для v=1.1 и ниже, то "убираем его" (сам процесс "уборки" -- отдельная песня), после чего браузер скажет о невозможности отображения данного объекта и необходимости установки плагина. Но здесь речь идёт всё-таки именно об объектах, а не

да и область применения такого подхода достаточно узкая. Как, например, в случае с Flash-объектами. Но, раз уж написал этот параграф,... не выкидывать же?

Идём ещё дальше...

В конечном итоге всё сводится к тому, что всё-таки проще написать расширение с набором компонент, которые после установки расширения лежат себе спокойно в каталоге components/ безо всяких перемещений по plugins/ и тихо делают своё чёрное дело.

Если там надо чего -- могу помочь, пока время свободное есть.

Ах, да... Есть ещё варинт.

В самом плагине задать временной интервал и пинговать определённый адрес на проверку обновлений и потом, при наличии обновлений, извещать пользователей (или, опять же, просто "убивать" плагин). Просто сам я не сторонник таких методов, когда пользватель не может повлиять на такие параметры (время/необходимость обновления).

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

Ну что ж, ответ исчерпывающий, большое спасибо.
xpi вариант понятен в принципе, его можно попробовать, но общий вывод пока - написать вместо плагина расширение и не париться.

>Дурной вопрос, просто "от незнания": имеет ли плагин доступ к атрибуту "pluginspage" обрабатываемого в текущий момент объекта?
Да имеет, параметры передаются в функцию NS_NewPluginInstance в виде nsPluginCreateData.

Вот насчет "убивать плагин" - не получается, т.к. когда пользователь заходит на станицу, FF подгружает dll плагина. Даже когда плагин не используется он может ее не освободить.

Пока буду пробовать и выяснять можно ли поменять плагин на расширение

Можно попробовать не удалять plugin.name.dll, а переименовывать (в trash.del, например). Операция переименования возможна даже если плагин "занят". Правда не знаю, получится ли сделать это из самого плагина.

Но, в любом случае, я тоже склонен думать, что вариант с расширением принесёт меньше пара.

Сейчас ради интереса открыл страницу с объектом Flash и, не закрывая браузера, переименовал plugins/NPSWF32.dll в plugins/__NPSWF32.dll. Рефреш страницы -- объект продолжает обрабатываться. Перезагрузка браузера -- надпись о необходимости установки плагина для отображения объекта.

Ага, точно, переименовать можно. Подумаю как это использовать. Проблемка-то в том, что если открытая страничка будет пользовать новый плагин с каким-то добавленным интерфейсом, то пока плагин не проапдейтить, она будет неправильно работать.

Нашёл nsIPluginManager. После переименования DLL делаем

Components.classes["@mozilla.org/plugin/manager;1"]
          .getService(Components.interfaces.nsIPluginManager)
          .reloadPlugins(true);

И вуаля.

В том подходе, о котором я говорил выше (проверка версии в атрибуте "pluginspage") есть один коварный момент: некто из злостных побуждений может выставлять там заведомо большие значения и, при заходе на такие страницы, пользователи будут постоянно устанавливать якобы более свежие версии плагина.

Спасибо, буду пробовать