[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Old Flash? Go upgrade! - New problem with konqueror
From:       koos vriezen <koos.vriezen () gmail ! com>
Date:       2010-04-18 11:08:29
Message-ID: m2vd4e708d61004180408jcb1d48fp2a2484a068dba578 () mail ! gmail ! com
[Download RAW message or body]

2010/4/18 koos vriezen <koos.vriezen@gmail.com>:
> 2010/4/15 Maksim Orlovich <mo85@cornell.edu>:
>>>    Hi
>>>
>>> Some days ago appear new problem with youtube. Each time konqueror try to
>>> play
>>> movie, message "Old Flash? Go upgrade!" is showed, and movie play is
>>> stopped.
>>
>> <snip>
>> Thanks for doing the analysis. Basically, what's needed is to implement
>> the npruntime module, for more sophisticated scripting of plugins
>> (including Flash) than what's supported now.
>
> Confirmed that GetVariable("$version") call on a flash plugin return
> the version using the flash support of kmplayer plugin.
> However, I can currently only get it by calling it after the plugin is
> loaded, eg in body.onLoad.
> So 'appendFlash = body.appendChild(flash)) && appendFlash.GetVariable'
> will only work when starting a local event loop for the time the
> plugin is up and running. Known to crash konqueror on unfortunate
> redirects (*).

Quick hack with enter/exitLoop doesn't work. Have no debug build of
kdelibs here atm, using debian/eperimental 4.4.2, but I guess the part
creation is not called at the moment js executes
'body.appendChild(flash))', right?
Actually, if I remove 'body.removeChild(flash);', the plugin never
load (unlike chrome).

Koos


>
>
>> Unfortunately, it's extremely
>> tricky to fully implement with out-of-process plugins, especially since
>> the presently used IPC system, D-Bus is inadequate for the task.
>
> Why? You mentioned that before and I only recall that the lack of
> nested calls. But dbus supports nested calls just fine.
> (*) That said, using the Qt eventloop for IPC is the source we cannot
> block safely. Currently thinking about a way to block w/o running
> processEvents (no OnlySocketNotifiers afaics), eg something with
> qprocess waitForStarted(), waitForReadyRead() or so.
>
>> It's been in my TODO list for a while, but looks like it suddenly got very
>> urgent. Let's see if I can dig up the old patch that partly supported it,
>> at least.
>>
>> Anyone reading looking for a challenge? ;-)
>
> We also need a LiveConnect2Extension. As mentioned before, the string
> based argument list/return value is too limited. We need at least a
> way to pass proxies of js objects as arguments. On these proxies
> get/put/call should be possible. Maybe simply use QVariant with a user
> type for the proxy can work.
>
> Koos
>

[prev in list] [next in list] [prev in thread] [next in thread]