[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:       "Maksim Orlovich" <mo85 () cornell ! edu>
Date:       2010-04-18 17:25:08
Message-ID: 60450.67.246.70.185.1271611508.squirrel () webmail ! cornell ! edu
[Download RAW message or body]


> Pretty sure I've seen a nesting call, js calls plugin, plugin
> evaluates some js code, depending on the result, the return value of
> the initial call is determined.

Could be a matter of different objects?

>>> 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.
>>
>> Definitely. Could I ask you to review the API once I get there?
>
> Sure :-).

One question is how much do we want to support, and under what model?
npruntime exports things like deleting & enumerating properties, as well
as using objects as constructors, which is very ES-like; yet it also has
things like invokeMethod, which ought to be equivalent to getProperty &
invokeDefault. Do you have any insight on how that parallel is handled by
Flash --- would getting 'GetVariable' and doing invokeDefault on it work?

> Btw this particular case is really easy to solve using the current
> nsplugin liveconnect object.
<snip helpful example>
>
> Yep, not a fully npruntime module, but good enough to fix the plugin
> loading thing in khtml (which of I have the feeling is a major task
> too  afair the plugin widget creation was triggered by the rendering)

Hasn't been the case for many years now, actually, though I am sure the
details vary somewhat. I probably need to force myself to read through
html5's mess of a language... (I know iframes in particular are different,
since in other places they always create an HTML document that wraps the
content in an embed or a pre; something else I need to fix, but that's not
the issue here).

In the case of the example... Well, we do get into
HTMLPartContainerElementImpl::computeContent on the appendChild, and
that's the method that should normally request the part, doing that on
::close
and not ::attach as well ... and the reason we don't load the plugin is
that the source is null, and

if (!embed && effectiveURL.isEmpty() && (effectiveServiceType.isEmpty() ||
classId.isEmpty()))

fails. I am pretty sure it should just be
if (!embed && effectiveURL.isEmpty() && effectiveServiceType.isEmpty())

(looks like I made a logic error when shuffling methods, both reversing
the sense of something, and since known classIds have already been
shuffled into effectiveServiceType). Or, in a patch form:

--- html/html_objectimpl.cpp    (revision 1110535)
+++ html/html_objectimpl.cpp    (working copy)
@@ -500,7 +500,7 @@

     // If there is no <embed> (here or as a child), and we don't have a
type + url to go on,
     // we need to render alternative as well
-    if (!embed && effectiveURL.isEmpty() &&
(effectiveServiceType.isEmpty() || classId.isEmpty()))
+    if (!embed && effectiveURL.isEmpty() && effectiveServiceType.isEmpty())
         newRenderAlternative = true;

     if (newRenderAlternative != m_renderAlternative) {

Note that it will pass in the page URL as the source, though. Is this
enough to make things work with kmplayer's viewer?

-Maks


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