Упаковка плагинов Mozilla (FireBreath) в .xpi для FireFox? - PullRequest
0 голосов
/ 30 октября 2011

Возможно, это связано с Использование плагина, созданного с помощью Firebreath в расширении Firefox? ;тем не менее, мой вопрос, возможно, более конкретен, так что здесь ...

Я работаю над Linux (Ubuntu 11.04), и я создал плагин Mozilla / Firefox (Firefox 7) с использованием FireBreath.Получившийся плагин для этой платформы представляет собой файл "npXXX.so", который я получил в виде ссылки ~/.mozilla/plugins.Затем я кодировал расширение, которое использует этот плагин - и кроме символической ссылки, кажется, больше ничего не требуется - все работает просто разбивая :)

Итак, зная, что " firefox поддерживает установку вашего плагиначерез XPI. Это не рекомендуется командой FireBreath", теперь я все еще хотел бы упаковать расширение И плагин в файл XPI.Итак, я читаю немного о Структура устанавливаемого комплекта - MDN , и я вижу эти две возможности:

/components/*   XPCOM components (*.js, *.dll), and interface files from *.xpt  (>=1.7)
...
/plugins/*  NPAPI Plugins   (>=1.8)
...
binary-component components/linux/mycomponent.so ABI=Linux_x86-gcc3

Теперь он говорит: "Старые API-интерфейсы для плагинов на основе XPCOM и LiveConnect не должны использоваться.", поэтому я предполагаю, что каталог" /components "должен не использоваться (даже если он приведен в качестве примера ввыше страница).И я нигде не могу найти это явно, но я предполагаю, что FireBreath создает плагины NPAPI - так что, вероятно, «/plugins» - это путь.( Также есть упоминание о "/platform", но в нем четко сказано, что он устарел для Firefox> 3,6 ).

Хорошо, пока все хорошо ... Поэтому я пытаюсь скопировать файл плагина в plugins/linux внутри каталога расширений:

cp -L ~/.mozilla/plugins/npXXX.so plugins/linux/

...и затем вставьте следующее в chrome.manifest:

binary-component    plugins/linux/npXXX.so ABI=Linux_x86-gcc4

... затем я заархивирую весь каталог расширений (включая плагин) как .xpi, попробую установить его на другой компьютер.Там успешно устанавливается .xpi, файл .so действительно распаковывается в каталог профиля extensions/XXX/plugins/linux/, и каждый кросс-платформенный (javascript) код расширения работает нормально;за исключением того, что плагин не может быть найден.

Теперь, конечно, пользователь может самостоятельно символически связать расширение .so с ~/.mozilla/plugins/;тем не менее, я хотел бы избавить пользователя от этого :)

Как мне поступить с такой упаковкой - есть ли рекомендуемый способ сделать это?

Заранее большое спасибо за любые ответы,
Приветствия!

Редактировать: найдено Доставка плагина в виде набора инструментов - MDN , которыйтребует только install.rdf, а plugins/obj.so требуется;затем я обнаружил Запуск Quake Live в Firefox 4, 5 и 6 в Linux [исправлено внутри] , ссылаясь на QuakeLivePlugin_433-modded_ff10.xpi , и этот действительно следует такому простомуструктура .. Если я установлю это, я получу как расширение Quake, так и плагин Quake (и даже при жалобе консоли ошибок " Не удалось прочитать файл манифеста chrome "/path/to/extensions/quakeliveplugin@idsoftware.com/chrome.manifest '.") .... но если я попробую то же самое с моим плагином FireBreath (например, просто install.rdf и плагин в /plugins), будет показано только расширение - без плагина (и без разумногосообщения об ошибках) .. Может ли это быть проблемой с FireBreath?

1 Ответ

1 голос
/ 30 октября 2011

Хорошо, я опубликую это как ответ - я только что подтвердил, что плагин FireBreath действительно работает, будучи упакованным простым способом "набора инструментов" как расширение .xpi.

По сути, я только что очистил профиль Firefox своего ПК для разработки и попытался установить туда .xpi, несущий плагин, - и на ПК разработчика плагин показывает примерно следующее: плагины и работают очень хорошо (даже если он просто распакован в профиле / extensions / EXT / plugins / obj.so, а не в ~ / .mozilla / plugins) ... На самом деле я упаковал расширение и плагин в отдельные файлы .xpi, которые затем были объединены в один как рекомендовано в Multiple Item Package - MDN - и это тоже отлично работает ( при загрузке объединенного xpi, один получает запрос об установке двух расширений - одно для плагина, несущего одно, а другое для "обычное" расширение ) ...

Таким образом, проблема была только на другом тестовом компьютере - и проблема, кажется, в том, что я использую библиотеки Gnome в плагине, и в то время как мой компьютер разработчика - Ubuntu 11.04 - я думаю, что этот тестовый компьютер был Ubuntu 10.04 .. Так что, вполне вероятно, проблема несовместимых библиотек Gnome в сборке плагина; к сожалению, я не получаю много ошибок от Firefox, даже если я делаю:

NSPR_LOG_MODULES=IPCPlugins:5 NSPR_LOG_FILE=/tmp/plugins.log /path/to/firefox -P myprofile

(... как рекомендовано в Регистрация многопроцессных плагинов - MDN - однако /tmp/plugins.log остается пустым). Единственное, что Firefox на проблемной машине плюет, это что-то вроде stdout:

WARNING: Application calling GLX 1.3 function "glXCreatePixmap" when GLX 1.3 is not supported!  This is an application bug!
WARNING: Application calling GLX 1.3 function "glXDestroyPixmap" when GLX 1.3 is not supported!  This is an application bug!
(firefox:6548): GLib-GObject-WARNING **: /build/buildd/glib2.0-2.24.1/gobject/gsignal.c:1149: unable to lookup signal "text-insert" for non instantiatable type `AtkText'

... и я не могу сказать, имеет ли это какое-то отношение к плагину или нет ... Но я думаю, что, по крайней мере, часть упаковки была подтверждена как работающая :) Приветствия!

РЕДАКТИРОВАТЬ: Через некоторое время Firefox на тестовом ПК сделал выплюнул следующее (, хотя я ожидал, что это сообщение мгновенно всплывает ):

LoadPlugin: failed to initialize shared library /path/to/profile/extensions/extXXX/plugins/npXXX.so [/usr/lib/libstdc++.so.6: version ``GLIBCXX_3.4.14' not found (required by /path/to/profile/extensions/extXXX/plugins/npXXX.so)]

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

...