[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 17:13:17
Message-ID: x2hd4e708d61004191013y48d74f3fya8f726c9e1779acd () mail ! gmail ! com
[Download RAW message or body]

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.
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)
kmplayerpart constrructor sees

name= "__khtml__pluginembed"  value= "YES"
name= "__khtml__pluginbaseurl"  value=
"http://localhost/~koos/yt-flash-version.h
name= "__khtml__classid"  value= ""
name= "__khtml__codebase"  value= ""
name= "width"  value= "400"
name= "height"  value= "300"

Btw. long time ago, I made sure to add __khtml__foo as last, avoiding
conflicts with object attributes (ie. normally one looks at the
QStringList from start to end). See what happens if one add
__khtml__pluginbaseurl as attribute.

>> passing docbase is problematic though.
>
> Firefox doesn't seem to, yep. Probably need to avoid completeUrl somewhere
> in khtmlpart (plus hack nspluginloader to work with this). Can't test out
> whether empty URL works the same as null, though --- either FF or DiamondX
> crashes on me.
>
>> The test case works now fine too (had added setAttribute for
>> width/height/src).
>
> As above --- what exactly did you need to change, and why?

See above

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

> Anyway, I looked at html5, and it doesn't specify this behavior,
> though it does suggest that the state of plugin should be re-evaluated
> when the <object> is removed from document. Probably an oversight in
> the spec --- testing firefox with DiamondX, it does destroy the plugin.

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.


>> On youtube, I hear old flash audio through the newly opened page. This
>> is unrelated to this patch.
>
> But quite possibly to the above closeUrl problem, correct?

Yep

>> Heard that yesterday already for some
>> youtube links that still worked (eg. http://www.youtube.com/vpro still
>> works w/o this patch)
>
> Do you have a good way of reproducing it? If so, I can post a patch to
> destroy the plugin on removal from document. Should be simple.

100% reproducable, so yes I have.


>> I've build kdelibs/4.4 branch and copied libkhtml.so over the debian
>> version. Had a few crashes where it other times went just fine:
>>
>> #0  0x00007ffff77cef45 in *__GI_raise (sig=<value optimized out>)
>>     at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> #1  0x00007ffff77d1d80 in *__GI_abort () at abort.c:88
>> #2  0x00007ffff77c808a in *__GI___assert_fail (
>>     assertion=0x7fffe82321d6 "!minMaxKnown()", file=<value optimized out>,
>>     line=77,
>>     function=0x7fffe8236180 "virtual void
>> khtml::RenderReplaced::calcMinMaxWidth()") at assert.c:78
>> #3  0x00007fffe7fff8d8 in khtml::RenderReplaced::calcMinMaxWidth
>> (this=0xc71f68)
>>     at
>> /home/koos/doc/projects/kde-svn/kde/branches/KDE/4.4/kdelibs/khtml/rendering/render_replaced.cpp:77
>
> 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?

Koos

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