Flashplayer

[Maksim Orlovich]

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

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

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

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.

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

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