Can plugins interpret the HTML script tag?
D Herring
I started working on an NPAPI plugin to embed non-javascript languages
into HTML. The idea was to implement a system like FastCGI, but
client-side. When the plugin started, it would start the interpreter
program and use sockets to communicate.
The goal was for this plugin to be able to interpret scripts such as
<script type="application/x-myscript">
interesting non-javascript code here
</script>
Unfortunately, these scripts are not passed to my plugin (using FF
3.0.x), even after it is loaded by an <embed
type="application/x-myscript">. I could presumably have javascript
send the code, or have the plugin search the page for scripts; but
there has to be a better way...
Some plugins transparently support scripting for particular languages
(e.g. PyDOM and Kamen Lisp) but they seem to rely heavily on XPCOM.
Is there a reason why NPAPI was not designed to support this? Could
this ability be added?
Thanks,
Daniel
Georg Fritzsche
> Is there a reason why NPAPI was not designed to support this? Could
> this ability be added?
NPAPI developed historically from use-cases that were most important
back then, see Wikipedia [1] on this.
Its supported not only by Gecko but also by WebKit, Opera and probably
more. As there is no organization that officially defines the NPAPI
you can't just add something to it, only begin supporting it in one
browser-core and hope others jump on the wagon.
Regards,
Georg
Benjamin Smedberg
> The goal was for this plugin to be able to interpret scripts such as
>
> <script type="application/x-myscript">
> interesting non-javascript code here
> </script>
>
> Unfortunately, these scripts are not passed to my plugin (using FF
> 3.0.x), even after it is loaded by an <embed
> type="application/x-myscript">. I could presumably have javascript send
> the code, or have the plugin search the page for scripts; but there has
> to be a better way...
Do you mean something like:
<embed type="application/x-myscript">
custom script text here
</embed>
If so, then this won't work, because the way the <embed> tag is specified,
the inner content is displayed when the content type is unknown or
unsupported. You can, however, get it to load external scripts by URL, e.g.
<embed type="application/x-myscript" src="foo.myscript"></embed>
Or, using a more standard <object> tag:
<object data="foo.myscript" type="application/x-myscript"></object>
Or, perhaps you can embed the data directly using <param> tags:
<object type="application/x-myscript">
<param name="script" value="my script text...">
</object>
> Some plugins transparently support scripting for particular languages
> (e.g. PyDOM and Kamen Lisp) but they seem to rely heavily on XPCOM. Is
> there a reason why NPAPI was not designed to support this? Could this
> ability be added?
There is no reason NPAPI couldn't be used for this: the NPAPI scripting
model should allow you to create a bridge to other languages fairly easily:
the only significant problem you may encounter is managing object lifetime
correctly, since NPRuntime uses refcounting and this means it is possible,
even likely, to create reference cycles among objects.
https://developer.mozilla.org/en/Scripting_plugins
--BDS
D Herring
Portability is one of the main benefits of NPAPI. I'll try stirring
up some support for this feature; but in the meantime, I'll look at a
minimal javascript interface.
Thanks,
Daniel
D Herring
> On 11/29/09 1:56 AM, D Herring wrote:
>
>> The goal was for this plugin to be able to interpret scripts such as
>>
>> <script type="application/x-myscript">
>> interesting non-javascript code here
>> </script>
>
>
> <embed type="application/x-myscript">
> custom script text here
> </embed>
No. I really meant the <script> tag. Its defintion even hints that
it should support other languages (e.g. tcl or vbscript).
http://www.w3.org/TR/REC-html40/interact/scripts.html
> Or, perhaps you can embed the data directly using <param> tags:
>
> <object type="application/x-myscript">
> <param name="script" value="my script text...">
> </object>
That is a possible syntax to replace normal <script> blocks. However,
it makes script formatting difficult (e.g. escaping quotes). Also
there are other places that javascript can appear (see below).
>> Some plugins transparently support scripting for particular languages
>> (e.g. PyDOM and Kamen Lisp) but they seem to rely heavily on XPCOM. Is
>> there a reason why NPAPI was not designed to support this? Could this
>> ability be added?
>
> There is no reason NPAPI couldn't be used for this: the NPAPI scripting
> model should allow you to create a bridge to other languages fairly
> easily: the only significant problem you may encounter is managing
> object lifetime correctly, since NPRuntime uses refcounting and this
> means it is possible, even likely, to create reference cycles among
> objects.
>
> https://developer.mozilla.org/en/Scripting_plugins
I wrote the better part of a scripting plugin. But it wasn't getting
the script commands embedded in the HTML.
Here's an example from the PyDOM page: <button onclick="print foo"/>
It appears to me that there is no way to have FireFox pass "print foo"
directly to my NPAPI plugin without going through the javascript
parser. Going through javascript, PyDOM example becomes something like
<button onclick="myscript.eval(\"print foo\")"/>
My desire is that NPAPI plugins could add non-javascript languages as
first-class citizens. This is possible through XPCOM, but that isn't
as portable.
Thanks for your reply,
Daniel
Benjamin Smedberg
> I wrote the better part of a scripting plugin. But it wasn't getting the
> script commands embedded in the HTML.
>
> Here's an example from the PyDOM page: <button onclick="print foo"/>
>
> It appears to me that there is no way to have FireFox pass "print foo"
> directly to my NPAPI plugin without going through the javascript parser.
> Going through javascript, PyDOM example becomes something like
> <button onclick="myscript.eval(\"print foo\")"/>
>
> My desire is that NPAPI plugins could add non-javascript languages as
> first-class citizens. This is possible through XPCOM, but that isn't as
> portable.
That is correct. Although we did add some support for "language agnostic
DOM" for PyXPCOM, I don't think we now consider it important enough to spend
significant energy on it, and so I think we're unlikely to accept changes of
this magnitude (in Mozilla/Firefox anyway).
Actually adding support for <script type="application/x-mycustomscripttype">
is actually probably pretty trivial as an NPAPI extension, but again I
question the benefit/cost and whether we'd be willing to accept it. However,
if you'd like to propose such a NPAPI extension, please add it to
https://wiki.mozilla.org/Plugins under the "NPAPI Specifications Under
Consideration" section. It's much more likely to be considered if you
provide a working patch.
--BDS
Georg Fritzsche
> Actually adding support for <script type="application/x-mycustomscripttype">
> is actually probably pretty trivial as an NPAPI extension
Correct me if i'm overlooking something, but while there is the need
to utilize the NPAPI as a workaround for such things in the absence of
a cross-browser API for extensions, i don't see how this would fit
into the NPAPI in a official or semi-official way.
The NPAPI is targeted at extended embedded content, but a script-
interpreter is no content. It either breaks scripting rules if you
allow embedding (e.g. scripts don't work before the embedded
interpreter is loaded, the question of which interpreter is
responsible, ...) or breaks the common NPAPI behaviour if you define
that these interpreters are not embeddable.
That being said, i wonder why nobody ever tried to advocate a cross-
browser extension model.
Regards,
Georg
Benjamin Smedberg
> Correct me if i'm overlooking something, but while there is the need
> to utilize the NPAPI as a workaround for such things in the absence of
> a cross-browser API for extensions, i don't see how this would fit
> into the NPAPI in a official or semi-official way.
Why not? The NPAPI seems like a pretty good fit for this kind of script
execution, because it has a well-defined object scripting model already.
Flash, for example, is basically a script execution engine already, and
people already use 1x1 hidden flash objects just for its scriptability
(ability to play sounds, for example).
> The NPAPI is targeted at extended embedded content, but a script-
> interpreter is no content. It either breaks scripting rules if you
Script is content!
--BDS
Georg Fritzsche
> On 11/30/09 3:45 PM, Georg Fritzsche wrote:
>
> > Correct me if i'm overlooking something, but while there is the need
> > to utilize the NPAPI as a workaround for such things in the absence of
> > a cross-browser API for extensions, i don't see how this would fit
> > into the NPAPI in a official or semi-official way.
>
> Why not? The NPAPI seems like a pretty good fit for this kind of script
> execution, because it has a well-defined object scripting model already.
> Flash, for example, is basically a script execution engine already, and
> people already use 1x1 hidden flash objects just for its scriptability
> (ability to play sounds, for example).
Yes, i said its currently used as a workaround - but thats no reason
to encourage hacks.
And how could something like this work without breaking common NPAPI
behaviour:
<html>
<head><script type="application/x-foo">doX();</script></head>
<body><object type="application/x-foo"><!-- this isn't loaded early
enough --></object></body>
</html>
Ok, lets say these plugins with special attributes X are loaded for
the script-types and "automatically embedded" i still see at least two
non-trivial issues:
How would you handle multiple instances in the same page?
Is it really worth it to hack it into NPAPI instead as e.g. an
extension-based model if you consider all the overhead involved
resulting from lets say one interpreter instance per open document?
Just curious,
Georg
Benjamin Smedberg
> And how could something like this work without breaking common NPAPI
> behaviour:
> <html>
> <head><script type="application/x-foo">doX();</script></head>
> <body><object type="application/x-foo"><!-- this isn't loaded early
> enough --></object></body>
> </html>
I'm not suggesting hacks here, I'm suggesting an NPAPI extension, so that
<script type="application/x-foo"> would query plugins to see if they handle
that MIME type and invent a new enumeration value for NP_GetValue. Then
you'd load a single windowless plugin instance per page and pass it script
data to evaluate.
> Is it really worth it to hack it into NPAPI instead as e.g. an
> extension-based model if you consider all the overhead involved
> resulting from lets say one interpreter instance per open document?
What's the overhead? We're talking about a pair of NPP_New/NPP_Destroy calls
per page which use this script type, which is not a whole lot.
I don't think it makes any sense to focus on yet another extension-based
model when we've already got a perfectly good one.
--BDS
Georg Fritzsche
> I'm not suggesting hacks here, I'm suggesting an NPAPI extension, so that
> <script type="application/x-foo"> would query plugins to see if they handle
> that MIME type and invent a new enumeration value for NP_GetValue. Then
> you'd load a single windowless plugin instance per page and pass it script
> data to evaluate.
Ok, makes sense that way. I did have something else in my head.
Regards,
Georg