ctbk1989 / npapi-sdk Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/npapi-sdk
Automatically exported from code.google.com/p/npapi-sdk
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.
Original issue reported on code.google.com by [email protected]
on 16 Jun 2011 at 8:54
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 5 Sep 2011 at 7:36
Attachments:
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.
Original issue reported on code.google.com by RSATom
on 14 Nov 2011 at 7:44
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.
Original issue reported on code.google.com by [email protected]
on 6 Sep 2011 at 7:48
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
Original issue reported on code.google.com by [email protected]
on 20 Sep 2011 at 8:24
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.
Original issue reported on code.google.com by [email protected]
on 30 Aug 2011 at 4:21
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?
Original issue reported on code.google.com by [email protected]
on 27 Jan 2012 at 12:43
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;
Original issue reported on code.google.com by [email protected]
on 24 Feb 2012 at 12:05
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.
Original issue reported on code.google.com by [email protected]
on 20 Aug 2011 at 8:08
test
Original issue reported on code.google.com by [email protected]
on 19 Aug 2012 at 9:19
Attachments:
We should add Windows version of the basic plugin sample. Preferably one that
builds with minimal clicks via visual studio.
Original issue reported on code.google.com by [email protected]
on 2 Mar 2011 at 5:56
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
Original issue reported on code.google.com by [email protected]
on 1 Aug 2011 at 5:44
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.
Original issue reported on code.google.com by [email protected]
on 15 Jul 2011 at 8:39
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 8 Jan 2013 at 8:41
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);
Original issue reported on code.google.com by [email protected]
on 23 Feb 2012 at 10:17
https://wiki.mozilla.org/NPAPI:DocumentOrigin
Original issue reported on code.google.com by [email protected]
on 9 Sep 2011 at 5:19
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 20 Mar 2011 at 6:56
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 29 Jan 2013 at 3:11
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.
Original issue reported on code.google.com by [email protected]
on 9 Oct 2011 at 5:31
Attachments:
drop trailing whitespace in NPAPI headers
Original issue reported on code.google.com by [email protected]
on 25 Jun 2011 at 7:52
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.
Original issue reported on code.google.com by [email protected]
on 3 Dec 2012 at 6:18
https://wiki.mozilla.org/NPAPI:AsyncDrawing
Original issue reported on code.google.com by [email protected]
on 25 Apr 2012 at 1:05
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.
Original issue reported on code.google.com by [email protected]
on 20 Apr 2012 at 3:00
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 14 Jul 2012 at 4:37
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 24 Apr 2012 at 6:01
Attachments:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.