Flashplayer

[koos vriezen]

2007/10/19, Maksim Orlovich <mo85 at cornell.edu>:
> > 2007/10/18, koos vriezen <koos.vriezen at gmail.com>:
> >> It also supports calls from javascript to the plugin, as long as they
> >> don't require a return value.
> >
> > Oops, I forgot to start implementing this :-). Anyhow, like the
> > nsplugin, the other way around works.
>
> Since you've looked at it, how much more stuff do we need in the
> LiveConnect extension to support everything flash needs from npruntime?
> I've had nspluginviewer supporting some of it, but there were problems
> w/types, and flash was crashing all over the place for me.

What doesn't work for me is setting the QXEmbed or Q11EmbedContainer
as xembed container for the plugin directly, it gives gtk assertions.
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.
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.
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.
- 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:

    js_class.structVersion = NP_CLASS_STRUCT_VERSION;
    js_class.allocate = windowClassAllocate;
    js_class.deallocate = windowClassDeallocate;
    js_class.invalidate = windowClassInvalidate;
    js_class.hasMethod = windowClassHasMethod;
    js_class.invoke = windowClassInvoke;
    js_class.invokeDefault = windowClassInvokeDefault;
    js_class.hasProperty = windowClassHasProperty;
    js_class.getProperty = windowClassGetProperty;
    js_class.setProperty = windowClassSetProperty;
    js_class.removeProperty = windowClassRemoveProperty;

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.
The other direction seem to be by calling NPPVpluginScriptableNPObject
on the plugin, where javascript from the html page can do its gets and
calls.

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

Br.
Koos