bugGnash - The GNU Flash player - Bugs: bug #21930, Klash fails to load swf files from...


bug #21930: Klash fails to load swf files from http, works from filesystem, cvs 2008-01-01

Submitted by:  Fredrik Johansson <mumme>
Submitted on:  Wed 02 Jan 2008 11:55:28 AM UTC  
Category:  plugin Severity:  5 - Blocker
Release:  None Status:  Fixed
Privacy:  Public Assigned to:  Sandro Santilli <strk>
Open/Closed:  Closed

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sat 05 Jan 2008 08:51:01 AM UTC, comment #8: 

Thanks, no I don't see a reason for stdin read anymore indeed.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Sat 05 Jan 2008 07:40:22 AM UTC, comment #7: 

Yes I confirm it works correct.

" You can try the direct load easily in order to compare the two versions, just pass the url as argument rather then the local filename, basically drop the -u switch and keep the subsequent url..."

Thats what I did, but my version just hang on http://youtube.com/active_sharing.swf

I suppose I did something wrong with either downloading and/or writing to stdin. I dont think it was a gnash problem.

I attach a diff here If you would want to look at it (don't really see why though)

/ Fredrik

(file #14750)

Fredrik Johansson <mumme>
Sat 05 Jan 2008 12:12:11 AM UTC, comment #6: 

Alright, I committed a patch to the core handling the case in
which we want to load a movie from the filesystem by pretend
it was loaded from network.
The effect should be that access to the initial movie is granted
but no further access to any local resource.

This should actually open up the way to a stricter security
by dropping the addition of basedir of first loaded movie
to the local sandboxes (not done yet).

Anyway, the konqueror problem should be fixed now.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 04 Jan 2008 11:21:44 PM UTC, comment #5: 

YouTube is a problem on itself, I don't see why should complex animation fail while simple one succeed.
I'd surely like to know more about it.
You can try the direct load easily in order to compare the two versions, just pass the url as argument rather then the local filename, basically drop the -u switch and keep the subsequent url...

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 04 Jan 2008 10:37:00 PM UTC, comment #4: 

Ok I have tried 2 days to bring my dense head around this one, I managed to get a halfway solution loading from stdin trough KProcIO but it only worked on simple (ad)pages, not youtube etc. (didn't try gnashtests)

I don't think I manage to make it work, if you still want to see the changes please let me know.

In the meantime letting gnash do the load instead would probably be better.

/ Fredrik

Fredrik Johansson <mumme>
Wed 02 Jan 2008 02:13:32 PM UTC, comment #3: 

Ok, it makes sense.
A resource loaded from the network should not be granted
access to filesystem, unless explicitly granted by
gnashrc. In this case the resource is loaded
from network (virtually) even if a cache is actually
being used, so it is correct to forbid that.

Reading from stdin would require support from the hosting
environment (kde). You can see how we do for NPAPI
(plugin/plugin.cpp) for an example.

Maybe the quick hack of passing Gnash the full URL
would be good enough for 0.8.2.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 02 Jan 2008 02:03:36 PM UTC, comment #2: 

Ah I see, there was a good reason for letting the browser handle it.

About the debug-log, I didn't know of this, great that I could find it in the manual so quickly!

Yes I get a security warning, complete log:
2172] 14:55:06: Setting width to 800
2172] 14:55:06: Setting height to 700
2172] 14:55:06: Setting root URL to http://www.centralhobbies.com/Engines/parts/ys63s.swf
2172] 14:55:06: Setting base URL to http://www.centralhobbies.com/Engines/parts/ys63s.html
2172] 14:55:06: No rendering flags specified, using rcfile
2172] 14:55:06: DEBUG: Base url set to: http://www.centralhobbies.com/Engines/parts/ys63s.html
2172] 14:55:06: DEBUG: /tmp/kde-fredrikjohansson/konqueroroWnUnc.swf appended to local sandboxes
2172] 14:55:06: SECURITY: Load of file /tmp/kde-fredrikjohansson/konqueroroWnUnc.swf forbidden (base url http://www.centralhobbies.com/Engines/parts/ys63s.html is not a local resource).
2172] 14:55:06: ERROR: failed to open 'file:///tmp/kde-fredrikjohansson/konqueroroWnUnc.swf'; can't create movie
2172] 14:55:06: ERROR: Couldn't load library movie 'file:///tmp/kde-fredrikjohansson/konqueroroWnUnc.swf'

making it load from stdin seems way better, though I don't really know how to do that (I'm just a regular user.. no programmer)

/ Fredrik

Fredrik Johansson <mumme>
Wed 02 Jan 2008 12:13:15 PM UTC, comment #1: 

There's no good reason to download the movie before playing it,
unless --enable-write configure switch was specified, which is to download all initial movies started trought plugins.

For the NPAPI plugin we feed the movie using stdin.

Passing the full URL to gnash might not work in case
the SWF won't be returned unless a proper cookie or
referer is sent. Also, letting the browser take care
of the socket would also use caches when available
(as gnash does not implement a caching thing currently).

The problem seems the same of bug #21436 indeed, and same
as the problem Miriam Ruiz reported on gnash@gnu.org.
IIRC, in the mail from Miriam I saw a '-' in the "starting process" line. Could it be we're actually trying to load from stdin and failing ?

Do you see any SECURITY line in your debug log before the "Could not load movie" line ?

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 02 Jan 2008 11:55:28 AM UTC, original submission:  

Hi all,

This bug might be a duplicate of #21436, I dont know.

In any case when going to a flash enabled page with klash I get Could not load movie '/tmp/kde-fredrikjohansson/konquerorvjvkha.swf'

If I save the page and flashmovie to file system and browse from there, it works fine.

Digging through the source it seems that the plugin is downloading the swf instead of letting gnash handle it, not sure why but there is probably a god reason for that.

In any case if I comment out 2 lines and add http path instead of '/tmp/kde-$USER/konquerorXXXXXX.swf' it works fine.
I know that it's not a fix as it downloads the movie twice, I just wanted to prove my case.

my (temporary) fix:
Index: plugin/klash/klash_part.cpp
RCS file: /sources/gnash/gnash/plugin/klash/klash_part.cpp,v
retrieving revision 1.20
diff -r1.20 klash_part.cpp
<     if (!m_file.isEmpty ())
<         m_src_url = m_file;

> //     if (!m_file.isEmpty ())
> //         m_src_url = m_file;


>     m_src_url = url.url();

Hope it helps.

Fredrik Johansson

Ps. Did you know that kde konqueror trunk has Xembed support, not GTK sopprot though.

Fredrik Johansson <mumme>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #14750:  partlyworking.diff added by mumme (6KiB - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by strk (just as I belive you understood the local sandbox thing ;))
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by mumme (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-01-05 strk StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2008-01-05 mumme Attached File- => Added partlyworking.diff, #14750
    2008-01-05 strk StatusNone => Ready For Test
        Assigned toNone => strk
        Carbon-Copy- => Added bwy
    2008-01-02 strk Severity3 - Normal => 5 - Blocker

    Back to the top

    Powered by Savane 3.5