Plugins/Mozilla - Revision history

J-b at 11:07, 23 November 2010

2010-11-23T11:07:29Z

← Older revision		Revision as of 11:07, 23 November 2010
Line 155:		Line 155:

	The exported JavaScript API is documented in the [[Documentation:WebPlugin]] page. It is the same for the Mozilla-plugin and the [[ActiveX/HTML\|ActiveX]] component.		The exported JavaScript API is documented in the [[Documentation:WebPlugin]] page. It is the same for the Mozilla-plugin and the [[ActiveX/HTML\|ActiveX]] component.


			[[Category:Coding]][[Category:Building]]

Thannoy: /* Using */ new section to lonk to the JS API documentation

2009-08-26T07:33:25Z

Using: new section to lonk to the JS API documentation

← Older revision		Revision as of 07:33, 26 August 2009
Line 151:		Line 151:
	\| PluginNPN		\| PluginNPN
	\|}		\|}

			== Using ==

			The exported JavaScript API is documented in the [[Documentation:WebPlugin]] page. It is the same for the Mozilla-plugin and the [[ActiveX/HTML\|ActiveX]] component.

Jpd: /* NSPR_LOG_MODULES */

2009-08-25T13:35:39Z

NSPR_LOG_MODULES

← Older revision		Revision as of 13:35, 25 August 2009
Line 100:		Line 100:
	\| nsNativeModuleLoader		\| nsNativeModuleLoader
	\| xulrunner/XPCOM component loading		\| xulrunner/XPCOM component loading
			\|-
			\| nsHttp
			\| What the http layer is up to
			\|-
			\| nsSocketTransport
			\| Socket stuff
			\|-
			\| nsHostResolver
			\| DNS queries
	\|-		\|-
	\| mime		\| mime

Jpd: cannot drop the first heading from the toc. move toc aside instead.

2009-08-11T12:31:47Z

cannot drop the first heading from the toc. move toc aside instead.

← Older revision		Revision as of 12:31, 11 August 2009
Line 1:		Line 1:
			{\| align="right"
			\| __TOC__
			\|} <!-- really should skip MDC in the toc, but how? -->


	= MDC, the missing manual =		= MDC, the missing manual =

Jpd at 12:12, 11 August 2009

2009-08-11T12:12:13Z

@@ Line 6: / Line 6: @@
 Netscape Plugin Application Programming Interface (NPAPI) conforming plugins have a number of entry points that vary across platforms a bit in number and precise function per entry point. Those entry points together must mainly do two things: One) tell the browser what MIME-type(s) this plugin supports, and two) setup two function pointer tables.
-The first table contains pointers to functions inside the browser that the plugin may call. This table apparently must be copied to local storage and due to the structure will end up as a global for the plugin so it may as well be a statically allocated global, though there is a shutdown entry point to clean up any dynamic allocations after the last instance.
+The first table contains pointers to functions inside the browser that the plugin may call. This table apparently must be copied to local storage, but I haven't found why. The table necessairily will end up as a global for the plugin so it may as well be a statically allocated global, though there is a shutdown entry point to clean up any dynamic allocations after the last instance is destroyed.
 The second table contains pointers to functions the plugin exports to the browser to call. The browser will create a new instance by calling the new function pointer for each place in a webpage that the plugin is needed, and all the other functions will be called with a reference to such an instance.
@@ Line 16: / Line 16: @@
 "XPCOM plugins" may or may not be different from "xulrunner extensions". Clarification needed.
 == Compiling ==
@@ Line 22: / Line 48: @@
 <pre><nowiki>
-PKGCONFIG=`which pkg-config`
+PKGCONFIG=pkg-config
 MOZILLA_PLUGIN_CFLAGS=`$(PKGCONFIG) --cflags mozilla-plugin`
 MOZILLA_PLUGIN_LIBS=`$(PKGCONFIG) --libs mozilla-plugin`
@@ Line 103: / Line 129: @@
 | negotiateauth
 | Found in modauthkerb documentation
 |}

Jpd: Memory dump of mozilla related stuff

2009-08-11T10:58:52Z

Memory dump of mozilla related stuff

New page

= MDC, the missing manual =

This page contains some hard-won but still incomplete information that the boys at mozilla conveniently forget to tell you and that may be useful for developing mozilla plugins (such as our vlc plugin).

== General structure ==
Netscape Plugin Application Programming Interface (NPAPI) conforming plugins have a number of entry points that vary across platforms a bit in number and precise function per entry point. Those entry points together must mainly do two things: One) tell the browser what MIME-type(s) this plugin supports, and two) setup two function pointer tables.

The first table contains pointers to functions inside the browser that the plugin may call. This table apparently must be copied to local storage and due to the structure will end up as a global for the plugin so it may as well be a statically allocated global, though there is a shutdown entry point to clean up any dynamic allocations after the last instance.

The second table contains pointers to functions the plugin exports to the browser to call. The browser will create a new instance by calling the new function pointer for each place in a webpage that the plugin is needed, and all the other functions will be called with a reference to such an instance.

Enabling script interaction with the plugin should be done using the "NPAPI scripting extensions". This can be done by exporting the desired scripting interfaces through implementing NPObject derivates.

<blockquote>"And we've completely removed support for XPCOM plugins from Mozilla 1.9.2 (Firefox 3.6).<br>—<cite>Benjamin Smedberg  posting in mozilla.dev.tech.plugins on news.mozilla.org</cite></blockquote>

"XPCOM plugins" may or may not be different from "xulrunner extensions". Clarification needed.

== Compiling ==

Compiling a plugin is a bit sparsely documented but the gist seems to be to use <code>pkg-config mozilla-plugin</code> and to add a few choice flags. Thus on linux I have (which may or may not be correct):

<pre><nowiki>
PKGCONFIG=`which pkg-config`
MOZILLA_PLUGIN_CFLAGS=`$(PKGCONFIG) --cflags mozilla-plugin`
MOZILLA_PLUGIN_LIBS=`$(PKGCONFIG) --libs mozilla-plugin`

CXXFLAGS+=-fno-rtti -fno-exceptions -Wl,-z,defs -shared \
-O2 -g -DXP_UNIX -DMOZILLA_STRICT_API \
$(MOZILLA_PLUGIN_CFLAGS)
LDFLAGS+= -shared -Wl,-Bsymbolic \
$(MOZILLA_PLUGIN_LIBS)

npplugin.so: npplugin.o
$(CXX) $(LDFLAGS) $< -o $@

npplugin.o: npplugin.cpp

</nowiki></pre>

== debugging ==

One way to get more useful output out of nspr-based browsers (firefox, epiphany at least) is to set two environment variables:

export NSPR_LOG_FILE NSPR_LOG_MODULES
NSPR_LOG_FILE=path/to/log/file
NSPR_LOG_MODULES=modulename:level,modulename:level

However, I have failed to find a comprehensive list of modules to choose from.  <code>all:5</code> works but is perhaps a bit too verbose. The default for NSPR_LOG_FILE appears to be stderr. On windows the special ''WinDebug'' which redirects to OutputDebugString().

=== NSPR_LOG_MODULES ===
{| class="wikitable"
|-
! Module name
! function
|-
| all
| enable all log modules
|-
| sync
| enable unbuffered logging
|-
| timestamp
| prefix log messages with an UTC timestamp (NSPR 4.8 or later)
|-
| bufsize'':size''
| set the log buffer size
|-
| nsNativeModuleLoader
| xulrunner/XPCOM component loading
|-
| mime
| rowspan=6|MailNews applications (SeaMonkey/Thunderbird)<br> In debug builds also: imapoffline, bayesianfilter, msgcompose, mapi, nsaboutlookcardlog, nsabwinhelperlog, ldapautocomplete, nswabaddressbook, nsaboutlookdirectorylog, movemail, msgbiff, msgpurge, appleimportlog, import
|-
| imap
|-
| nntp
|-
| smtp
|-
| pop3
|-
| ldap
|-
| nsRDFService
| RDF service
|-
| nsXULTemplateBuilder
| template rule network construction and subsequent use
|-
| InMemoryDataSource
| Assert(), Unassert(), HasAssertion(), etc. for most datasources.
|-
| nsComponentManager
| XPCOM, clarification needed
|-
| MCD
| autoconfig?
|-
| HelperAppService
| ''save as'' related?
|-
| negotiateauth
| Found in modauthkerb documentation
|}