Flashplayer

[koos vriezen]

2007/10/20, Maksim Orlovich <mo85 at cornell.edu>:
> >> Sounds like something is not letting go of a grab. Does kmplayerpart run
> >> its plugin host as a separate process, or inside the konq process?
> >
> > Separate process
>
> So it's konq/QX11EmbedContainer that's causing trouble/lockup.

It looks like it, ie. killing only the knpplayer process doesn't help.
Nevertheless, it might be the knpplayer doing wrong things triggering
this.

> >> And is implementing these enough for Flash not to crash?
> >
> > I never had a crash of npplayer, other than obvious temporary typos
>
> I wonder if I screwed up then. The code is pretty complex (see the
> attached diff). Of course, if npplayer is nicer, may be it can serve as a
> base, if George doesn't mind. At some level, I'd like something like
> kmplayer to be a reasonably core component for embedding, so people can
> benefit from its cool compatibility/embedding features w/o going for the
> app in keg.

The nspluginscanner can detect whether the plugin needs xembed or not
(NPPVpluginNeedsXEmbed) and launch its viewer depending on this.

> >> Here, we have no type information on the arguments, to setup the
> >> npruntime
> >> structures. Similar stuff on put, get. Perhaps just pushing through the
> >> LiveConnectExtension's notion of types along would be sufficient.
> >> I think I'll e-mail my WIP patches here for further discussion once I
> >> get
> >> home.
> >
> > I rely on js' typeof to get the types. It's poor but the types in
> > npruntime are int32, bool, double, string or object. I don't see how
> > to detect argument type requirements of a certain call.
>
> Well, you can't detect, but I figure it would make sense to have the
> LiveConnectExtension pass them down from JS. I don't quite understand how
> you would even do this typeof thing, I guess I should look at the code..

I do that now, but only from plugin to browser. The typeof is
evaluated on the return type. The other way is more or less already
covered by current liveconnect types, but as I haven't really try to
implement this, I can't be sure.

> >> The part that I do wonder about is whether we'll ever have to deal with
> >> passing a custom JS object to a call, or returning one... I guess you
> >> already answered this since location is an object, but we may be able to
> >> get away with special-casing one. Otherwise, one needs inter-process GC
> >> and all other "fun" stuff one alluded to.
> >
> > I don't see why a call like document.plugin.setOutput(document.input1)
> > would be a problem where document.input1 is of type
> > NPVariantType_Object.
>
> Well, you would have to have a wrapper for the document.input on the
> browser end which forbids it from being GC'd, and connect it w/the
> NPObject's refcount and all that. And there is a possibility of cycles.
> (For more fun, note that one can theoretically pass functions across --- I
> don't know whether that case is ever used, since supporting it will
> require proxy objects on both sides).

The cheap way, as I do it now too, is to put the passed objects to an
array that is put on the js side of the plugin, eg.
'this.someid=document.input1, passing 'this.someid' as reference to
the plugin (this is the DOM object of the plugin). So if the plugin
wants to sets its content, ie do 'jsobject.value="some content"', it's
evaluated as 'this.someid="some content"'
Solving both the cross refs as preventing gc runs. However it's poor indeed.
Better have a truly interface for this.

> > The reentrance works AFAIR w/ the Java plugin. The problem is when
> > both side are in a code path that passes a call to the otherr side.
> > That will deadlock. So only one side can block and I think that should
> > be the konqueror side (with some sane timeout set). The plugin side
> > should therefor start a local eventloop (we know by now that in
> > konqueror this is deadly).
>
> I don't see how it makes sense. If konqueror blocks, and the plugin makes
> a call, what can you do? You can't interupt the plugin... Ahh. I remember
> my discussion w/Thiago now.. What we have to do is make the return values
> separate messages... So you get a call from konq, finish it up Q-DBus
> wise, and afterwards, from the main plugin loop do npruntime reply. konq
> is blocked meanwhile (hopefully w/o an event loop --- perhaps talking to
> an another thread that's spinning in an event loop). Then the plugin's
> call can be interpreted by konq as method invocation or a return, and
> acted upon appropriately. Very CPSish

My idea is based on interleaving dbus calls. Actually I don't know if
this is possible or not. Remembering a discussing in Waldo's days, I
thought it does. Ie. when a process makes a dbus call with reply, it
still is able to process incoming calls. As long as konqueror only
passes calls with the correct codepath-id back to js, it's no
different for kjs than a normal call in the kjs library.
We must block konqueror as we can't block the js calling chain
otherwise. Entering event loops are evil, eg. timers can cause reload
in the wrong eventloop causing crashes (calling js stack returns in a
deleted global object).
If dbus doesn't allow incoming requests while waiting for a reply
message, we're screwed (at least for 'get' and 'call' with return
values types) in the current status. Maybe this is solvable in JS,
dunno.(*)
On the npp side, when starting a local event loop, also new calls may
come either from konqueror (collision) or from the plugin, but these
are easily detected and error'ed returned.

(*)btw if you read the appletviewer code, it actually does create a
local loop, filtering out 'close' events and because khtml part does
one redirect by a reload (thanks to the popup dialog issue we once
had) it can be done so too. But rather not if possible.

Koos

> I guess that's about what you were suggesting..
>
>