zkjun / npapi-sdk Goto Github PK

What steps will reproduce the problem?

1. const char * mimeDescription = NP_GetMIMEDescription();
2. ...
3. NPP_New(mime, ...)

What is the expected output? What do you see instead?

I expect the code to compile. Instead, I see an error "cannot convert from 
'const char *' to 'char *'". Using non-const char* means that plugin can modify 
its mimetype at any time. I don't see this requirement anywhere. So I think 
plugin would only modify its local copy and shouldn't impact the browser.

What operating system are you compiling on?

Doesn't matter.

Please provide any additional information below.

This is actually a general issue with all readonly data passed as pointers. I 
think headers should clearly state which parameters are intended for output and 
which aren't.

actual: NPP_NewProcPtr (NPMIMEType pluginType, ...)
expected: NPP_NewProcPtr (const NPMIMEType pluginType, ...)

actual: NPP_NewStreamProcPtr(..., NPMIMEType type, ...)
expected: NPP_NewStreamProcPtr(..., const NPMIMEType type, ...)

actual: NPP_WriteProcPtr(..., void* buffer)
expected: NPP_WriteProcPtr(..., const void* buffer)

actual: NPP_SetValueProcPtr(..., void *value);
expected: NPP_SetValueProcPtr(..., const void *value);

I've noticed that ndata is not used. At least on plugin side.
WebKit plugin implementation has a correspondence table between NPP_t* and 
PluginView*. So it is not used in WebKit. Not sure about Mozilla.
So I see no reason to change ndata. Could it be marked as deprecated?

If some browsers still use it, it shouldn't be changed on plugin side.
In that case I propose to define a macro NPAPI_SDK_PLUGIN_CONST if 
NPAPI_SDK_BROWSER is not set.

Similarly, browser should not modify pdata.

So the changes would be:

#ifndef NPAPI_SDK_BROWSER # define it if you're browser developer
#define NPAPI_SDK_PLUGIN_CONST const
#define NPAPI_SDK_BROWSER_CONST
#else
#define NPAPI_SDK_PLUGIN_CONST
#define NPAPI_SDK_PLUGIN_CONST const
#endif

typedef struct _NPP
{
  NPAPI_SDK_BROWSER_CONST void* pdata;      /* plug-in private data */
  NPAPI_SDK_PLUGIN_CONST void* ndata;      /* netscape private data */
} NPP_t;

What steps will reproduce the problem?
1. Install Flash 10.3 NPAPI plugin for Solaris
2. Install Chromium for Solaris, which I've ported
3. Load site with Flash video

What is the expected output? What do you see instead?
Flash video plays.  Instead, the Flash plugin doesn't work and the following 
error message is seen on the console:

Not GTK2 toolkit (got 0).

What operating system are you compiling on?
Solaris Express 2010.11 i86pc

Please provide any additional information below.
It appears that starting with Flash 10.2 for Solaris (as Flash 10.1 works fine 
with Chromium), Adobe checks NPNVToolkit to make sure it's Gtk2.  Chromium 
tries to set this flag in plugin_host.cc (lines 758-762: 
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/plugins/npapi/plugin_host
.cc?view=annotate) but apparently it still comes out zero.  I logged the code 
and found that Flash looks for NPNVToolkit with the identifier 13, while 
Chromium uses the number 268435469 as the identifier for NPNVToolkit, so it 
never reports back with the right toolkit.  Looking further into npapi.h, I 
found that this is because the NP_ABI_GCC3_MASK is applied to NPNVToolkit, when 
it's defined.  My attached patch modifies npapi.h to only apply the ABI mask 
for gcc 3, not for gcc 4 also, and Flash 10.3 starts working with Chromium 
again.

Looking into why this ABI mask was applied in the first place, apparently it 
was to account for an ABI change from gcc 2 to gcc 3 
(https://bugzilla.mozilla.org/show_bug.cgi?id=182117#c18).  However, I guess it 
was simply assumed back then that gcc 4 would have the same ABI as gcc 3 (that 
patch was applied a couple years before gcc 4 came out), which may not be the 
case.  I find it crazy that all these compiler-specific modifications snuck 
into NPAPI, as noted in comment 15 on that mozilla bug.  This bug is not 
reproducible with Firefox 3.6 for Solaris as Oracle compiles Firefox with the 
Oracle Studio Compiler, not with gcc.

It's also possible that the NPAPI Flash plugin for Solaris is compiled with 
Oracle Studio and not with gcc, so the real issue is that only one compiler 
should be used with NPAPI on Solaris.  I don't know if this is the case or if 
the gcc ABI changed again.

I don't quite understand how it's possible to use npapi-sdk for browser 
development.

The problem is in NP_Initialize, NP_Shutdown, NP_GetMIMEDescription and other 
NP_* functions.

As defined in npfunctions.h they are exported. But when a browser includes 
npfunctions.h and compiles it will encounter linking errors because NP_* 
functions are not defined in browser's code (and they shouldn't). How is this 
supposed to work? Maybe some define guard should be introduced?

What steps will reproduce the problem?

1. Download latest revision(r21) of npapi-sdk headers

2. Create, in the same folder as the headers, a file a.c:
#include "npfunctions.h"
#include <stdio.h>
int main(int argc, char *argv[])
{
  return 0;
}

3. With the MinGW Shell go to said folder and run:
gcc a.c

What is the expected output? What do you see instead?

The expected output is an executable: a.exe

Instead, I see a lot of errors related to 'uintptr_t' and 'bool' being unknown 
type names.

What operating system are you compiling on?

Windows XP, MinGW GCC 4.7.2

Please provide any additional information below.

I believe the reason for this issue is nptypes.h assuming that WIN32 has no 
knowledge of C99. It may be true for MSVC, but isn't true for MinGW( and 
probably not true for Cygwin, and maybe others, too).

In nptypes.h, if I replace, in line 47:
#if defined(WIN32) || defined(OS2)
with:
#if (defined(WIN32) && !defined(__GNUC__)) || defined(OS2)
the issue is resolved, for me.

What steps will reproduce the problem?
1. Include npapi.h in bare bones plugin
2. Try to build (defining XP_UNIX and MOZ_X11
3. Failure

What is the expected output? What do you see instead?
A successful build without the MAEMO enums defined.

What operating system are you compiling on?
Ubuntu 10.04

Attached is a patch to first check if the macro is defined before comparing 
it's value.

If this is supposed to be a serious project, it should have a build system to 
install the header files and a pkg-config file as requested in another bug.

In the chromium project, the fact that OpenGL.h is included in npapi.h on mac 
has proven troublesome.  Including this header pulls in a large number of 
#defines, typedefs, and global symbols.  npapi.h is included in fairly common 
headers in the chromium project via some IPC-related headers to serialize types 
and we've accumulated various hacks to work around collisions such as: 
http://code.google.com/searchframe#OAMlx_jo-ck/src/content/browser/renderer_host
/render_message_filter.cc&exact_package=chromium&ct=rc&cd=37&q=npapi.h&sq=&l=108
5

This include exists to support the NPDrawingModelOpenGL rendering model, which 
as far as I know has never been supported and likely never will be supported by 
any browser.

We should add Windows version of the basic plugin sample. Preferably one that 
builds with minimal clicks via visual studio.

See the attached patch. Eg. NP_Initialize uses OSCALL that specifies the 
calling convention, but NP_InitializeFunc does not. It means that if someone 
stores pointer to NP_Initialize in a variable of type NP_InitializeFunc and try 
to call it, the call will be done with wrong (platform default) calling 
convention. The attached patch fixes it.

The alternative fix would be to use:

typedef typeof(NP_Initialize) NP_InitializeFunc;

but that's less portable.

Hi,

I Need a tutorial or sample code to develop NPAPI Plugin for Safari5.1 from 
scratch,I have tried to download the sample from the link 
"http://mxr.mozilla.org/mozilla2.0/source/modules/plugin/sdk/samples/basic/mac/"
and even I posted this issue on stackoverflow at 
"http://stackoverflow.com/questions/6882779/how-to-checkout-the-source-code-from
-http-link".

I have seen from the link "http://code.google.com/p/npapi-sdk" to check out the 
source code for simple
npapi sample using "svn checkout http://npapi-sdk.googlecode.com/svn/trunk/ 
npapi-sdk-read-only"
But my terminal is saying "svn: OPTIONS of 
'http://npapi-sdk.googlecode.com/svn/trunk': could not connect to server 
(http://npapi-sdk.googlecode.com)"

What is the expected output? What do you see instead?
Expected a debuggable NPAPI plugin sample  for Safari5.1

What operating system are you compiling on?
Mac OS10.6

Any help would be  appreciated.


Thanks & Regards,
Akbar

test

What steps will reproduce the problem?
1. simple make Linux BasicPlugin r6 on fresh check out
2. Load Html 


<!--
    Auto-generated test-site
-->
<html>
<head>
<title>test page for object</title>
</head>
    <script type="text/javascript">

    </script>
<body onload="">
<object id="plugin0" type="application/basic-plugin" width="300" height="300">
</object><br />

</body>
</html>




The error produced is:

1) Black screen in pluginarea.
2) Console print:

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_new: assertion `drawable 
!= NULL' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_set_rgb_fg_color: 
assertion `GDK_IS_GC (gc)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_draw_rectangle: assertion 
`GDK_IS_DRAWABLE (drawable)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_set_rgb_fg_color: 
assertion `GDK_IS_GC (gc)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_set_values: assertion 
`GDK_IS_GC (gc)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_draw_rectangle: assertion 
`GDK_IS_DRAWABLE (drawable)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_draw_layout: assertion 
`GDK_IS_DRAWABLE (drawable)' failed

(plugin-container:16151): GLib-GObject-CRITICAL **: g_object_unref: assertion 
`G_IS_OBJECT (object)' failed

(plugin-container:16151): GLib-GObject-CRITICAL **: g_object_unref: assertion 
`G_IS_OBJECT (object)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_new: assertion `drawable 
!= NULL' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_set_rgb_fg_color: 
assertion `GDK_IS_GC (gc)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_draw_rectangle: assertion 
`GDK_IS_DRAWABLE (drawable)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_set_rgb_fg_color: 
assertion `GDK_IS_GC (gc)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_gc_set_values: assertion 
`GDK_IS_GC (gc)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_draw_rectangle: assertion 
`GDK_IS_DRAWABLE (drawable)' failed

(plugin-container:16151): Gdk-CRITICAL **: IA__gdk_draw_layout: assertion 
`GDK_IS_DRAWABLE (drawable)' failed

(plugin-container:16151): GLib-GObject-CRITICAL **: g_object_unref: assertion 
`G_IS_OBJECT (object)' failed

(plugin-container:16151): GLib-GObject-CRITICAL **: g_object_unref: assertion 
`G_IS_OBJECT (object)' failed



What operating system are you compiling on?
 Firefox 18 on Linux Mint 14

http://code.google.com/p/npapi-sdk/source/browse/trunk/headers/npapi.h#104 

According to http://code.google.com/p/npapi-sdk/source/detail?r=5
NP_GetMIMEDescription prototype has changed (added "const"), but we have no any 
possibility determine that fact via C++ preprocessor.

The unix basic plugin compiles fine shows up in firefox and chrome. 

When runing a page with the plugin it doesnt show anything but it doesnt crash 
either.

Through the command line chrome is giving this

(exe:1334): Gdk-CRITICAL **: IA__gdk_gc_new: assertion `drawable != NULL' failed

(exe:1334): Gdk-CRITICAL **: IA__gdk_gc_set_rgb_fg_color: assertion `GDK_IS_GC 
(gc)' failed

(exe:1334): Gdk-CRITICAL **: IA__gdk_draw_rectangle: assertion `GDK_IS_DRAWABLE 
(drawable)' failed

(exe:1334): Gdk-CRITICAL **: IA__gdk_gc_set_rgb_fg_color: assertion `GDK_IS_GC 
(gc)' failed

(exe:1334): Gdk-CRITICAL **: IA__gdk_gc_set_values: assertion `GDK_IS_GC (gc)' 
failed

(exe:1334): Gdk-CRITICAL **: IA__gdk_draw_rectangle: assertion `GDK_IS_DRAWABLE 
(drawable)' failed

(exe:1334): Gdk-CRITICAL **: IA__gdk_draw_layout: assertion `GDK_IS_DRAWABLE 
(drawable)' failed

(exe:1334): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT 
(object)' failed

(exe:1334): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT 
(object)' failed

https://wiki.mozilla.org/NPAPI:AsyncDrawing

Fairly minor thing; I can't find any plugin out there that exports this, short 
of demo ones. But may as well correct it to match NP_GetMIMEDescription's fix. 
Mozilla's already casting the function to the const version anyway.

http://mxr.mozilla.org/mozilla-central/source/dom/plugins/base/nsPluginsDirUnix.
cpp#359

Patch attached.

Purpose of code changes on this branch:

https://wiki.mozilla.org/NPAPI:ContentsScaleFactor

When reviewing my code changes, please focus on:

Making sure it's awesome.

After the review, I'll merge this branch into:
/trunk

In the Linux ecosystem npapi plugins are often built using devel package 
instead of adding the headers to its own source code.
Up to now these applications checked for mozilla-plugin.pc for example which 
was pretty much standardized between Linux distributions.
With the new release model and this npapi-sdk reference project it makes sense 
to provide this a development package in a Linux build environment. But it does 
not yet contain a pkgconfig template. The contents of that file are pretty 
obvious in the Linux environment but to have a standard naming of the pkgconfig 
file it makes sense to add a template file which makes it clear so that this is 
consistent through different Linux distributions which makes it a lot easier 
for upstream plugin authors to add another pkgconfig check in their buildsystem.

For the upcoming version of openSUSE I've added the headers as devel package 
named npapi-sdk to the distribution and also I'm using the pkgconfig name 
npapi-sdk.pc as well. But right now we have to patch the other applications 
ourselves because it's not clear how other distributions will name the 
pkgconfig file.

When trying to build icedtea-web NPAPI plugin with npapi-sdk:

/tmp/portage/dev-java/icedtea-web-1.1.1-r1/work/icedtea-web-1.1.1/plugin/icedtea
np/IcedTeaNPPlugin.cc: In function 'char* NP_GetMIMEDescription()':
/tmp/portage/dev-java/icedtea-web-1.1.1-r1/work/icedtea-web-1.1.1/plugin/icedtea
np/IcedTeaNPPlugin.cc:2266:24: error: new declaration 'char* 
NP_GetMIMEDescription()'
/usr/include/npapi-sdk/npfunctions.h:303:24: error: ambiguates old declaration 
'const char* NP_GetMIMEDescription()'

The change introduced in rev5 is causing this breakage. I'm not sure if it 
might not break ABI as well on some exotic arches.

My suggestions is reverting it now, and coming back to it when a good migration 
plan is established. If it's actually worth breaking that whole lot of packages.

For your convenience, attaching patches to revert the changes.

https://wiki.mozilla.org/NPAPI:DocumentOrigin

What steps will reproduce the problem?
1. Compile with gcc446
2.
3.

What is the expected output? What do you see instead?
Compilation without error, but error occurs due to a calling convention

What operating system are you compiling on?
OS/2

Please provide any additional information below.
NP_CALLBACK should be used

Google Chrome version: 10.0.648.151:
Operating System:         Windows 7 
Error Message:              "Missing Plug-in"

I have a NPAPI API based (scriptable) plugin developed using Gecko SDK 1.9.2. 
This plugin works fine on FF3.6 & FF4 beta, but it fails to get detected on 
chrome.

But I could see the plugin listed - when I do a _"about:Plugins"_ in chrome.  
I've registered the plugin as described in the "[Windows Installation Using the 
Registry][1]".

When monitored the chrome startup using Sysinternals tool Procmon.exe, I could 
find that the chrome tries to do a LoadImage on my Plugin dll, quickly after 
that I get "Missing Plug-in" error in the screen.

Any ideas why this plugin is not detected by chrome will help.


  [1]: https://developer.mozilla.org/en/Gecko_Plugin_API_Reference/Plug-in_Development_Overview#MS_Windows

drop trailing whitespace in NPAPI headers

Whereas Issue#9 presented the fact that NPAPI doesn't have an actual API 
version number but instead has an ABI version number, and

Whereas Issue#9 presented the need for an actual API version number, and

Whereas the lack of intention for source-level compatibility to date does not 
mean it isn't worthy goal,

Be it resolved that an additional #define be added to the npapi-sdk, which can 
be combined along with the ABI version represented by NPAPI_VERSION_MAJOR + 
NPAPI_VERSION_MINOR , such as "NPAPI_VERSION_REVISION" , to create an actual 
API version that can be checked for and relied upon within plugin code.

Helper #defines, to support a simple #if statement to check required version 
info in plugin codes, would also be very nice.

Adding this new revision number to the versioning scheme in the pkg-config file 
would also be very helpful.