Flashplayer

[koos vriezen]

2007/10/19, Maksim Orlovich <mo85 at cornell.edu>:
>
> > What doesn't work for me is setting the QXEmbed or Q11EmbedContainer
> > as xembed container for the plugin directly, it gives gtk assertions.
>
> To be honest, I haven't really looked at this XEmbed stuff. (and unlike
> you, I am not willing to deal with gtk).. But this sounds like something
> we would need help to debug; perhaps some gtk'ish folks could give an idea
> of what the assertions are. If you don't know anyone, I can probably
> network up someone.
>
> > So now I set a gtksocket as window and add this this to a gtkplug
> > child. The gtkplug is then embedded in the QXEmbed or
> > Q11EmbedContainer.
>
> So there are 2 levels of embedding, or is there a yet-another process
> involved there?

Two processes, konqueror and the knpplayer process. Yes 2 levels,
plugin inside a gtksocket, this gtksocket is a child of a gtkplug
(which is a sub classed gtkwindow) forming the knpplayer and that one
is embedded inside a QXEmbedContainer which is in the konqueror
process by loading th kpart.

> > Unfortunately this isn't quite working all the time using the xembed
> > protocol. In kde3 I've worked around this by using the XPLAIN option.
> > In Qt4/KDE4 there is no such option anymore, so I'm still figuring out
> > what's causing this failures.
>
> Perhaps Seli or Fredrik can offer some advice, I'll try to bug them.
>
> > The failures are not easy reproducable, occurring just once in a
> > while. And comes down to two different issues.
> > - the keyboard focus stay on the plugin, ie tabbing shows yellow
> > rectangles in the flash movie moving, but clicking or hovering outside
> > the plugin, doesn't seem to send mouse events to the windows. This is
> > really grave as it complete 'locks' the desktop. Only killing
> > konqueror helps, but that can only be done from another virtual
> > terminal, like a ssh login (or since I run kde4 in Xephyr, outside of
> > this Xserver.
>
> 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

> > - the cpu goes 100% and the konqueror process keeps on posting
> > MetaCall (43) events to the Q11EmbedContainer widget. This doesn't
> > lock up konqueror though.
>
>
>
> >
> > The NpRuntime requirements can be seen by what I have now registered
> > as functions in the NPClass structure:
>
>
> <snip stuff I already know>
>
> >
> > The plugin can ask the NPNVWindowNPObject, which represents the
> > 'window' of the caintainer document. Typically the plugins queries
> > this object for 'location' and then the href property. 'location' goes
> > first by using the getProperty, where I return a NPObject of type
> > NPVariantType_Object and on that one the 'href is queried, which
> > return a NPObject of type NPVariantType_String.
>
> And is implementing these enough for Flash not to crash?

I never had a crash of npplayer, other than obvious temporary typos

> > I can't oversee now what exactly we need extra for the latter, we
> > already have get/put/call/unregister so that might already be enough.
> > But implementing this will show what extra is needed.
>
> The part that bothered me was this:
>   virtual bool call( const unsigned long objid, const QString & func,
> const QStringList & args, Type & type, unsigned long & retobjid, QString
> & value );
>
> 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.

> 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.

> > The former I now have wrapped everything by generating js scripts and
> > using the 'evaluate' call. This works but its really primitive. Eg. to
> > keep track of objects and to prevent objects from being garbage
> > collected, one needs to use a js array. So I think having the same
> > get/put/call/invalidate in the direction of plugin->javascript will
> > make things much cleaner.
>
> The problem is what happens if the plugin does a call in response to a
> call from JS. D-Bus, to my best understanding, will deadlock. Even w/DCOP,
> when this sort of thing will go through due to key tracing, I am not 100%
> sure KJS and KHTML will be able handle this sort of reentrancy gracefully.

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).
It will require an administration with eg. a codepath id, that makes
sure that a reentrant call has the same id as the one we're waiting
for, and if not, return an error.

Br.
Koos

> Mike Melanson, if you're reading, can flash ever make a request to a
> browser in response to a method invocation from it?
>
>
>
>