[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-19 20:44:29
Message-ID: j2id4e708d61004191344w3ac49bd0u67db49ada974d080 () mail ! gmail ! com
[Download RAW message or body]

2010/4/19 Maksim Orlovich <mo85@cornell.edu>:
>> 2010/4/19 Maksim Orlovich <mo85@cornell.edu>:
>>>
>>>> With some hacking, I indeed get youtube working.
>>>
>>> Could you elaborate on what exactly you had to do? I am a bit lost here.
>>
>> Like mentioned kmplayer I had to make sure the plugin creation goes
>> sync, had to bypass a few timeout redirects too.
>
> OK. nspluginviewer's startup is embarrassingly sync, so that's one thing I
> probably don't have to worry about.
>
>> Also I need the correct src/movie url, not the docbase. The kpart
>> constructor gets the width/height attribute, but not the src
>> attribute. Modified the test case as
>>
>> ...
>>    flash.setAttribute("type", "application/x-shockwave-flash");
>>    flash.setAttribute("width", "400");
>>    flash.setAttribute("height", "300");
>>    flash.setAttribute("src", "lux.swf");
>>    if ((appendFlash = body.appendChild(flash)) && appendFlash.GetVariable)
>> {
>>                 version = appendFlash.GetVariable("$version");
>>    };
>>    body.removeChild(flash);
>>    document.write(version);
>> ..
>> (so width/height/src added)
>
> See, this is what I am confused about. Shouldn't the testcase work
> w/o an actual flash file (and also w/o width and height)?

Yes it does, sorry for the confusion. I hadn't unedit my changes after
applying your first fix.

> The khtml bug I see it that it views the empty string as relative to
> document, and hence completes it to the page URL (might be right for empty
> but not null, too). I would think the right thing to do would be to pass
> an empty string to openUrl? nspluginviewer has some code for that (it just
> does the wrong thing).

Anyhow I just add a special case when the url passed in parts openUrl
is either empty or equal to docbase in case the OpenUrlArguments has
type flash.
I think khtml should pass the real src/movie, but a probe might indeed
pass docbase too.

FWIW currently in kmplayer it conflicts a bit with real plugin
grouping support. After I recently had upgraded the moz-sdk,
/usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/amd64/libnpjp2.so also
started to work somehow, so I need to rethink this a bit in the
future.

>>>> KHTML also seems to forget calling closeUrl in the test case
>>>> 'body.removeChild(flash);'.
>>>
>>> closeUrl, or destroying the plugin instance entirely, I wonder?
>>
>> Either way are fine with me.
>
> Please see the attached. I would appreciate if you told me if it
> fixes the youtube-still-playing-sound issue for you.

Yes it does, do see the probe plugin over the final plugin, but that
might be because everything on my side is in flux. Just spit the
plugin set up in a create only and a first-stream adding part. The
latter still after a timeout, so that would solve the initial test
case perfectly.
Please backport this to 4.4 too once your satisfied with it, including
yesterdays fix.

>> At the end of the script, the 'flash' variable goes out of scope, so
>> no reference to this DOM object. Might be the cause of destruction
>> too, dunno.
>
> Well, going out of scope doesn't mean much since garbage collection might
> not happen for a long time.

Yeah I thought that as well. Doesn't the gc suck in cases like this,
no? (I mean, leaving scoped variables unnecessary burden the gc later)

>>> This one should be fixed in more recent versions, if my memory serves me
>>> right.
>>
>> My 4.4 checkout is from yesterday. Can the fix be backported then?
>
> Hmm. It should have been fixed by r1077278, which is way older than that.
> Might be a different bug hitting the same assert then.

Haven't seen it today yet. Maybe my fault, dunno

Koos

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