Swfdec/Konqi integration

[koos vriezen]

2007/6/19, koos vriezen <koos.vriezen at gmail.com>:
> 2007/6/19, Kevin Krammer <kevin.krammer at gmx.at>:
> > On Tuesday 19 June 2007, koos vriezen wrote:
[..]
> > > > What's the difference of manipulating js objects and evaluating scripts?
> > >
> > > The problem is that js objects need to be stored somewhere for the
> > > livetime of the NPObject's. I've now assigned these to variables of
> > > the embed DOM object. But that is of course a hack, as it exposes
> > > internal stuff to the javascript of the container page.
> >
> > Hmm, ok. NPObjects are on the side of the plugin, i.e. data structure within
> > the plugin runner's address space? In the case of in-process plugins, where
> > does the browser store their counterparts?
>
> It's probably a direct reference to the js object. Unfortunately
> kparts can't do that. Some long time ago I proposed[1] an addition to
> kparts, so kparts could pass their kjs interpreter to each other. We
> really need something like that to implement this or else all we have
> 'evaluate'.

First I apologize for polluting your spec thread with my out loud
thinking how I can safely implement this in current kpart
implementation.

But I just though of a way to make this 'public' exposure of internal
npobject refs hidden. Since liveconnect::get/put when returning false
will cause kjs to assign a javascirpt variable to the DOM embed
object, which I currently use as reference, I can of course set a flag
when running an 'evaluate' so it will return 'false' and when the flag
is not set, it will return a string 'Access denied'. And 'put' will
simply ignore the assignment. As ecma first goes through the
liveconnect and then check its dynamic props, it actually works.
Only the variable names itself shows up in the 'for (i in
document.applets[0])' list but that's not serious I think.

No doubt everyone reading my concerns was nodding his head for this
obvious extra hack ..

Koos