Bug 16716

Created attachment 17679 [details]
file displaying the current URL

Looks like we'll want implement this as close to the WRONG way as possible.

The reason for this is that SwfdecURL is meant to do what the Flash player does when handling urls. And the Flash player happily puts all the characters into the URL as they are ignoring (as usual) any standards out there.

But we definitely want to have something like swfdec_url_(from|to)_real_url() and make swfdec_url_from_input() use this.

(In reply to comment #1)
> Created an attachment (id=17679) [details]
> The reason for this is that SwfdecURL is meant to do what the Flash player does
> when handling urls. And the Flash player happily puts all the characters into
> the URL as they are ignoring (as usual) any standards out there.

I don't think you understood the problem. The issue is not with how flash files are interpreted (so Adobe's plugin's behavior is not relevant to the discussion). The issue is with swfdec's API.

- The swfdec API includes functions with a parameter that can be interpreted both as a url (or part of a url) and as a pathname on disk (or part of a pathname).
- Which happily ignores the fact that urls are in URI encoding while local pathnames are in UTF-8. And there are no flags to specify which encoding the parameter is in.
- When local pathnames with non-ASCII characters are involved, the API provides no way to construct a SwfdecURL object whose url and path fields are both valid and consistent with each other.
- The SwfdecURL object is used, among other things, to specify where to load the flash files from.
- Outside the browser, Swfdec relies on its own loader classes to do IO. Those loaders assume that the fields of the SwfdecURL object are valid and consistent.

(In reply to comment #1)
> Created an attachment (id=17679) [details]
> file displaying the current URL

Interesting. Swfdec-mozilla shows a valid URL (file:///home/me/%D0%B8%D0%B1%D1%80%D0%B0%D0%B6%D1%8B.swf).

Meanwhile, both swfdec-player and Adobe's plugin show an invalid URL (file:///home/rostovts/ибражы.swf).

Now, Firefox certainly calls Adobe's plugin with a valid URL. My guess is that Adobe's plugin is printing the display form (.toString() or something) of the URL object instead of the actual URL string...

Created attachment 17683 [details]
swf file that tests whether encoded URLs work

As can be seen from this test file, Adobe's plugin expects URLs to be in valid URI encoding; if the URL is raw UTF-8, it won't load.

(Note that this example does not work on swfdec-0.6.6 for some reason)

---------
.flash filename="urltest.swf" bbox=400x100 version=7 background="#dddddd"

.action:
        var url1 = "%D0%B8%D0%B1%D1%80%D0%B0%D0%B6%D1%8B.swf";
        var url2 = "ибражы.swf";
        createTextField("t0", 0, 0, 0, 400, 20);
        t0.text = "Try click on the relative URLs below";
        createTextField("t1", 1, 0, 30, 400, 20);
        createTextField("t2", 2, 0, 60, 400, 20);

        var f1 = new TextFormat();
        f1.url = url1;
        t1.text = "Encoded URL works: " + url1;
        t1.html = true;
        t1.setTextFormat(f1);

        var f2 = new TextFormat();
        f2.url = url2;
        t2.text = "UTF-8 URL does not load: " + url2;
        t2.html = true;
        t2.setTextFormat(f2);
.end
.end

Created attachment 17694 [details] [review]
swfdec-0.6.6-uri-encoding.patch

Patch to fix the problem.

What it does:

1. Documents what fields, parameters and return values are supposed to be in filesystem encoding (the parameter to swfdec_url_new_from_input(), so long as it doesn't look like a URL), and which ones are URI-encoded (everything else).
2. Adds URI-encoding logic to swfdec_url_new_from_input()
3. Adds a function for converting URI-encoded strings to UTF-8
4. Adds URI-decoding logic to swfdec_url_format_for_display()
5. Adds URI-decoding logic to SwfdecFileLoader.

With this patch, swfdec-player correctly opens weirdly-named swf files both from Nautilus, from command line, and from its own file dialog. And even the window title is correct!

The patch is for swfdec-0.6.6, but it seems to also apply OK to 0.7.2.

Fixed in git.