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

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

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

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

Да не секрет, это автоматический редирект на одну программку - 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/ и тихо делают своё чёрное дело.

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

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

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

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

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

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

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

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

И вуаля.

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