RFC --- new scripting extension sketches.

[koos vriezen]

2010/5/5 Maksim Orlovich <mo85 at cornell.edu>:
> Hi.. Please see the attached file for what I sketched out thus far for a
> replacement for LiveConnectExtension. It doesn't address quite a few
> things
> --- see comments on top --- but I figure I should probably get some
> feedback before going overboard.

- eval stuff, something like
     bool evaluate(const QString &script, QString &result);
for nsplugin this is a requirement, flash injects quite some js into
the container page.
Maybe add a script language as extra argument.

- exception propagation

returning false is an exception condition I guess

- ScriptValues, I suggested using QVariant and a user type for the js
object proxy. Your ScriptValue class seems to be enough for nsplugin
though. However if e.g. a kpart hosting app want to retrieve a QImage
from a image viewer kpart, it can probably hack it in, but QVariant is
definitely more friendly.

The wrapped object table example seems to me unnecessary,
nspluginviewer can use the NpObject pointer as objectid, the caller of
a function should deref the arguments after the call, likewise for the
result object as for property setters.
The kpart object owner is indeed needed and should be packet in the
parts own object implementation. In case of nsplugin, a sub classed
NpObject and in case of khtml, a JSObject sub class, me thinks


> (As for missing stuff, at the very least, I want evaluation to be more
> direct, other than using this.__nsplugin-type tricks).
>
> Hmm, obvious flaw noticed when about to hit send: I need to represent the
> execution context for the XSS checks.

What I miss is the back direction of this.
So a kpart creates a ScriptableExtension object as QObject child. The
hosting application, when creating the part, calls
"static ScriptableExtension* childObject(QObject* obj)", and then the
normal flow of "openUrl()". Next the kpart want to get an object form
its host (e.g. flash always queries for 'window' and then
'window.location' etc, plus injecting large amounts of js).
In the old LiveConnect, there was only the 'evalutate()' signal. So
here I would suggest that after the hosting app queried for the
extension, it sets its own ScriptableExtension object for the scenario
described above. Something like
  bool setHost( ScriptableExtension *);

Koos