NPAPI вызывает перенос аргументов
Я написал плагин NPAPI, который содержит два типа плагинов:
- х-захват используется для захвата видео с камеры
- х-дисплей используется для отображения изображений, снятых объектами x-capture
и у меня есть следующий код HTML / JavaScript, который использует плагин:
<html>
<embed id="display" type="application/x-display" width=640 height=480 /></td>
<embed id="capture" type="application/x-capture" width=0 height=0 /><br> <!-- windowless plugin -->
<script>
var capture = document.getElementById('capture');
var display = document.getElementById('display');
capture.addDisplay(display);
</script>
</html>
Моя проблема в том, что вызов addDisplay в моей библиотеке получает в качестве аргумента вызова другой указатель NPObject, чем тот, который связан с экземпляром предоставленного x-display.
Также член _class полученной структуры NPObject отличается от того, который я предоставил при создании объекта сценариев x-display.
После попытки перечислить методы полученных объектов (из функции handleAddDisplay), чтобы узнать больше о типе полученного аргумента, я получил стек вызовов, который включает в себя nsJSObjWrapper (я тестирую его в Firefox / Windows). Моя библиотека — это npCaptureDemoPlugin.dll. В конце оболочка вызывает перечисление экранного объекта.
npCaptureDemoPlugin.dll!RendererPlugin::hasMethod(void * name=0x06311d00) Line 84 C++
npCaptureDemoPlugin.dll!ScriptableObject<RendererPlugin>::Class::hasMethod(NPObject* object=0x191fd0b4, void * name=0x06311d00) Line 382 + 0x43 bytes C++
xul.dll!NPObjWrapper_NewResolve(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4c0, int id=0x06311d00, unsigned int flags=0x00000001, JSObject * * objp=0x003cb838) Line 1659 C++
mozjs.dll!CallResolveOp(JSContext * cx=0x13bf8f60, JSObject * start=0x0650c4a0, JS::Handle<JSObject *> obj={...}, JS::Handle<int> id={...}, unsigned int flags=0x00000000, JSObject * * objp=0x003cb8dc, JSProperty * * propp=0x003cb8d4, bool * recursedp=0x003cb883) Line 4637 + 0x1b bytes C++
mozjs.dll!js_LookupProperty(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, int id=0x06311d00, JSObject * * objp=0x003cb8dc, JSProperty * * propp=0x003cb8d4) Line 4745 + 0x7a bytes C++
mozjs.dll!JS_LookupPropertyById(JSContext * cx=0x00000000, JSObject * obj=0x0650c4a0, int id=0x06311d00, JS::Value * vp=0x003cb8e4) Line 3502 + 0x49 bytes C++
xul.dll!xpc_ForcePropertyResolve(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, int id=0x06311d00) Line 652 + 0x13 bytes C++
xul.dll!XPC_WN_Shared_Enumerate(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0) Line 605 + 0xe bytes C++
xul.dll!XPC_WN_JSOp_Enumerate(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, JSIterateOp enum_op=JSENUMERATE_INIT, JS::Value * statep=0x003cbaf4, int * idp=0x00000000) Line 1275 + 0x1b bytes C++
mozjs.dll!Snapshot(JSContext * cx=0x00000000, JSObject * obj=0x00000000, unsigned int flags=0x00000008, JS::AutoIdVector * props=0x003cbb78) Line 364 + 0x25 bytes C++
mozjs.dll!js::GetPropertyNames(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, unsigned int flags=0x00000008, JS::AutoIdVector * props=0x003cbb78) Line 440 + 0x1a bytes C++
mozjs.dll!JS_Enumerate(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0) Line 4241 + 0x34 bytes C++
xul.dll!nsJSObjWrapper::NP_Enumerate(NPObject * npobj=0x089cbd90, void * * * idarray=0x003cbf74, unsigned int * count=0x003cbf68) Line 968 + 0xe bytes C++
xul.dll!mozilla::plugins::parent::_enumerate(_NPP * npp=0x10eff7c8, NPObject * npobj=0x089cbd90, void * * * identifier=0x003cbf74, unsigned int * count=0x003cbf68) Line 1900 + 0xc bytes C++
npCaptureDemoPlugin.dll!NPN_Enumerate(_NPP * npp=0x10eff7c8, NPObject * obj=0x089cbd90, void * * * identifier=0x003cbf74, unsigned int * count=0x003cbf68) Line 254 + 0x18 bytes C++
npCaptureDemoPlugin.dll!CapturePlugin::handleAddDisplay(NPObject * object=0x089cbd90) Line 382 + 0x18 bytes C++
npCaptureDemoPlugin.dll!CapturePlugin::invoke(void * name=0x13855280, const _NPVariant * args=0x003cc270, unsigned int argCount=0x00000001, _NPVariant * result=0x003cc248) Line 142 + 0xf bytes C++
npCaptureDemoPlugin.dll!ScriptableObject<CapturePlugin>::Class::invoke(NPObject * object=0x191feb04, void * name=0x13855280, const _NPVariant * args=0x003cc270, unsigned int argCount=0x00000001, _NPVariant * result=0x003cc248) Line 414 + 0x4f bytes C++
xul.dll!CallNPMethodInternal(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c3a0, unsigned int argc=0x00000001, JS::Value * argv=0x05cd0070, JS::Value * rval=0x05cd0060, bool ctorCall=false) Line 1482 + 0x11 bytes C++
Похоже, что Firefox оборачивает мой NPObject в другой NPObject, тип которого я не могу обработать, и этот NPObject используется в качестве прокси для вызова моего объекта.
Мой вопрос: есть ли способ передать тот же NPObject в вызов функции, что и тот, который я связал с экземпляром плагина? Или есть другой способ проверить полученный объект в качестве аргумента вызова Invoke, что это ожидаемый тип, который я ранее создал? Или единственный способ — использовать некий родной идентификатор, переданный в JS и обратно в нативный код, чтобы я мог установить ассоциации между моими объектами?
Решение
Браузеры часто переносят NPObject из одного плагина перед тем, как передать его другому; Я предполагаю, что это мера безопасности, и это фактически означает, что вы не можете делать то, что хотите. Однако вы можете дать каждому объекту NPO некоторую форму уникального идентификатора и использовать метод getID для этого объекта. Тогда вам просто нужна карта или что-то подобное внутри, что вы можете использовать, чтобы получить реальный объект, который вам нужен после запроса getID через интерфейс NPObject.
Другие решения
Других решений пока нет …