bugGnash - The GNU Flash player - Bugs: bug #17586, plugin: getURL relative urls...

 
 

bug #17586: plugin: getURL relative urls should be resolved by browser when available

Submitter:  Dmitry Panov <dop251>
Submitted:  Fri 01 Sep 2006 06:33:17 PM UTC
   
 
Category:  None Severity:  3 - Normal
Release:  None Status:  Fixed
Privacy:  Public Assigned to:  strk
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 17 Nov 2006 12:21:18 AM UTC, comment #41: 

Refer to task #5919 for further discussion

Sandro Santilli <strk>
Group Member
Mon 09 Oct 2006 07:31:05 AM UTC, comment #40: 

I like the NPN approach too, but in order for that to work we need a comunication channel between the plugin and the standalone player, which is currently invoked by a system call (and we want to keep this setup, to have a better isolation).
Task http://savannah.gnu.org/task/?5919 is exactly meant for this.

Sandro Santilli <strk>
Group Member
Sat 07 Oct 2006 11:34:15 AM UTC, comment #39: 


What I'd like to use is the NPN API, so it would work
in any browser [1] (Mozilla, Firefox, konqueror etc.).

The idea is to substitute the call:
   string command = "firefox -remote \"openurl(";
with
   NPN_GetURL(_instance,url.str(),target_string);

but I don't see how to make it work, because is an NPN function
and I don't know how to call it from ASHandlers...

I've created a function in the plugin, but still don't know
how to call it from ashandler...

bool nsPluginInstance::NPNGETURL( const char* url, const char* target)
{
NPP npp = _instance;
        NPError err = NPERR_NO_ERROR;

        err = NPN_GetURL(npp,url,target);
        if (err != NPERR_NO_ERROR) {
     cout << "Plugin: Could not open the given URL!" << endl;
             return false;
        }
        return true;
}



See: http://developer.mozilla.org/en/docs/NPN_GetURL
for more info.

[1] Any browser that uses the NPN API.

Sebastià

Sebastiá Matas <annonygmouse>
Group Member
Sat 07 Oct 2006 07:33:23 AM UTC, comment #38: 


Sandro, exactly, the problem is the hard-coded call
of "firefos -remote".
However, I haven't had the time to digg into it to provide
any workaround. There are three areas I'd like to
investigate:

1.- Opening it directly via NPN
2.- Detecting the browser from where gnash has been called.
3.- Using some JavaScript and send it to the browser (probably
using NPN).

What do you think?

Anyway, I made a checkout yesterday and gnash is not able to
open the url even on firefox (where it used to work).
A good thing is that now the debugging output is also shown on
mozilla 1.7.X. It will make debugging easier.

Kind regards
Sebastià

Sebastiá Matas <annonygmouse>
Group Member
Fri 06 Oct 2006 10:27:35 PM UTC, comment #37: 

Sebastia' , could you argument again on this ? I'd like to understand the problem. Is the problem the hard-coded call of 'firefox -remote' ?
Is there an equivalent for mozilla (mozilla -remote) ?
And for other browsers ?
We can use an environmental variable if there are compatible
tools for all the browsers we intend to support.
The alternative is having plugins for each browser type open up a socket of fifo to emulate that -remote behaviour themself, and a gnash helper tool to act as a client for it.

Sandro Santilli <strk>
Group Member
Mon 02 Oct 2006 07:29:54 AM UTC, comment #36: 

firefox -remote "openurl()" is still what we do.
The problem was setting up the url to be fetched, as it seems
that relative urls are invalid with that call.
What we did was just adding to gnash the concept of a "base url"
which we extract from the plugin using JavaScript objects
interface.

So, what doesn't work for you ? Is it "base url" extraction?
(check the -U argument given to the executable)

... reset bug state to "ready for test" until all are
satisfied with it ...

Sandro Santilli <strk>
Group Member
Sun 01 Oct 2006 02:51:29 PM UTC, comment #35: 


I would like to re-open this bug, because
it only works for firefox.
The applied solution ASAIK is to create a new
firefox process with OPENURL and giving it the URL
to open.
This is browser dependent, in Mozilla it does
not work.

There should be other way of doing it.
I'll also try to look it up.

Sebastià

Sebastiá Matas <annonygmouse>
Group Member
Sun 01 Oct 2006 06:28:26 AM UTC, comment #34: 

Open a new item for the new tab thing. Please check what does firefox -remove 'geturl(absolute_url)' do with your installation
(that's what gnash invokes)

Sandro Santilli <strk>
Group Member
Sat 30 Sep 2006 10:07:47 AM UTC, comment #33: 

It works fine for me too in FF 1.5.0.4, thanks!
One small thing, the URL still opens in a new tab rather than in the same one.

Dmitry Panov <dop251>
Wed 27 Sep 2006 01:22:26 PM UTC, comment #32: 

Ok, support complete, voiptalk.org works for me !

Sandro Santilli <strk>
Group Member
Wed 27 Sep 2006 11:49:26 AM UTC, comment #31: 

I manually copied some entry points from a different sdk and it seems to still be working with firefox 1.0.4. Seems good !

Now I'll add the -U switch for gnash ...

Sandro Santilli <strk>
Group Member
Wed 27 Sep 2006 10:31:24 AM UTC, comment #30: 

It seems I found the NPN_GetStringIdentifier definition inside a different version of npn_gate.cpp file.

No more undefined reference, but won't work anymore with firefox 1.0.4 :((

Sandro Santilli <strk>
Group Member
Wed 27 Sep 2006 10:19:59 AM UTC, comment #29: 
Sandro Santilli <strk>
Group Member
Wed 27 Sep 2006 10:11:49 AM UTC, comment #28: 

It seems that the mozilla-dev package doesn't include any .cpp file at all. The NPN_GetStringIdentifier interface is still exposed in the header files, but can't find it's definition. Any idea of where should it be available from ?

After a successfull build, what I get at runtime is:

/usr/lib/mozilla-firefox/firefox-bin: relocation error: /newsys/src/gnash/build/gtk-opengl/plugin/.libs/libgnashplugin.so: undefined symbol: NPN_GetStringIdentifier

Sandro Santilli <strk>
Group Member
Wed 27 Sep 2006 06:41:32 AM UTC, comment #27: 

Now that I'm back home, on high bandwidth, I'll download the mozilla-sdk and see if I can take the javascript code in...

Sandro Santilli <strk>
Group Member
Tue 26 Sep 2006 08:22:55 PM UTC, comment #26: 

I'm pretty sure javascript objects will still be there even if javascript is disabled.


Dmitry Panov <dop251>
Fri 22 Sep 2006 09:43:52 PM UTC, comment #25: 

There must be some other way beside javascript (what if javascript is disabled?). Unfortunately the "Working with URLs" chapter of the Gecko reference is empty :(

Looking forward for more help in this.

Sandro Santilli <strk>
Group Member
Fri 22 Sep 2006 09:13:29 PM UTC, comment #24: 

I've finally prepared a testcase for my "external target" dubt:
http://foo.keybit.net/~strk/flash/tests/relative_urls_test/frameset.html

It seems that a single -U switch would suffice.
A quick test with your sample code shows that we didn't bring
into gnash enough parts of the mozilla SDK (NPN_GetStringIdentifier is undefined). I'll crawl trought the mailing list archive looking for the debian package name for those sources and try to add the missing bits.

Sandro Santilli <strk>
Group Member
Fri 22 Sep 2006 04:33:26 PM UTC, comment #23: 

Ok, I'll give this a try by providing a fixed "frame url" for a single run (a -U switch or similar). It would be worth to check what happens to relative urls when the 'target' window is not the window from which the SWF movie was loaded (would it resolve relative to the target window url OR the SWF-embedding window one?).

In the former case a -U switch would not suffice, and we'll really need a way for the standalone player to communicate with the plugin.

Sandro Santilli <strk>
Group Member
Thu 21 Sep 2006 05:17:17 PM UTC, comment #22: 

With NPAPI it is should be possible to get any property of any javascript object from the calling page. That includes document.location.href. I didn't try it but it should work.

For example:

        NPObject *window;
        NPIdentifier sDocument = NPN_GetStringIdentifier("document");
        NPVariant * vDoc;
        NPN_GetValue(npp, NPNVWindowNPObject, &window);
        NPN_GetProperty(npp,window, sDocument, &vDoc);
        NPN_ReleaseObject(window);
        if (!NPVARAINT_IS_OBJECT(vDoc))
           return FALSE;
        const NPObject & npDoc = NPVARIANT_TO_OBJECT(vDoc);
        NPIdentifier sLocation = NPN_GetStringIdentifier("location");
        NPVariant * vLoc;
        NPN_GetProperty(npp, npDoc, sLocation, &vLoc);
        NPN_ReleaseObject(npDoc);
        if (!NPVARIANT_IS_OBJECT(vLoc))
           return FALSE;
        const NPObject & npLoc = NPVARIANT_TO_OBJECT(vLoc);
        NPIdentifier sProperty = NPN_GetStringIdentifier("href");
        NPVariant * vProp;
        NPN_GetProperty(npp, npLoc, sProperty, &vProp);
        NPN_ReleaseObject(npLoc);
        if (!NPVARIANT_IS_STRING(vProp))
           return FALSE;
        const NPString & propValue = NPVARIANT_TO_STRING(vProp);
        return propValue.utf8characters; // const char *

Dmitry Panov <dop251>
Thu 21 Sep 2006 06:22:46 AM UTC, comment #21: 

In IE 4.5 and older  versions on Macintosh, relative links are resolved relative to the location of the .swf file, not the HTML file.

Yes, in most browser it is the other way around, so we might
make it a compile-time macro.

The problem is: how does the standalone player knows the url of
the HTML page ? We can add a -U switch, but could not find a way to extract current frame URL from the NSAPI. Suggestions welcome.

Sandro Santilli <strk>
Group Member
Wed 20 Sep 2006 07:38:09 PM UTC, comment #20: 

But I couldn't find a browser where voiptalk.org navigation doesn't work with the standard Macromedia plugin. With gnash I couldn't find a browser where it would work. I think it should be considered as a bug at least if the project's goal is to develop a drop-in replacement for Macromedia flash.

Dmitry Panov <dop251>
Tue 19 Sep 2006 07:59:48 AM UTC, comment #19: 

I've finally found informations about how GetUrl relative urls should be resolved. Source is Colin Moock's "ActionScript: The Definitive Guide".
Well, it seems there's no standard behaviour. This is listed under the "Bugs" section for the GetUrl() function.
Some browser resolve relative to the HTML page,
some other relative to the .swf movie.
So, if we were to change current behaviour we would still break
compatibility with some other browsers.

We do resolve relative to the .swf movie and that's it.

Sandro Santilli <strk>
Group Member
Mon 18 Sep 2006 04:59:09 PM UTC, comment #18: 

I can't find any pointer in the NSAPI dox about extracting url of current frame...
I haven't tried, but I think that using the NSAPI GetUrl method would resolve urls in the right way. In order for this to work we'd  need to communicate between the child (standalone) process and the parent (plugin) process.

Sandro Santilli <strk>
Group Member
Sun 10 Sep 2006 04:30:51 PM UTC, comment #17: 

Just executing "firefox absolute_URL" seems to do what's needed, it opens the URL in the current window or tab. I think adding another gnash parameter to tell it the base URL and launching "firefox <new_calculated_absolute_URL>" should do.

As for the "another target" problem I'm not sure how it would work with flash I haven't seen any examples but I think the relative URL would still be calculated based on the URL of the frame where the movie resides, so it's not a problem.

Dmitry Panov <dop251>
Sat 09 Sep 2006 10:28:47 PM UTC, comment #16: 

Auch, I did some "manual" firefox -remote invocation tests and it seems it is really broken by itself. Also found lot of references about problems reported by users...
For instance, relative URLs resolution doesn't work at all.
Note that the "open in new tab" bug seems also due to this problem.

I see no easy solution for this.

Sandro Santilli <strk>
Group Member
Sat 09 Sep 2006 09:50:41 PM UTC, comment #15: 

mmm.. this means that the getURL call should be done with the relative URL, leaving resolution to the browser. We can do that, but then any direct gnash invocation (not trough a browser) will lack the information about the url that is supposed to be opened, unless we provide it using another switch.

The -u switch we currently have will still be required for loadMovie actions, in which it's the parent movie's URL that
counts, not current windows'.

So... options are:

  - add another specific switch for the url of the "loader page"
  - use an environment variable (firefox might provide standard ones, in which case we might support that and let user use that to "fake" loads from within a browser.
  - Use a custom parameter value for use with -P

Actually, all of the above solution are still limited in that in case a target is another window then the one the movie has been loaded into, it's URL can change w/out any notification to the gnash executable, so we'd loose track of any way for resolving
relative urls..

Maybe a quick and dirty hack could be adding a switch to tell gnash that it's been called from the plugin and completely disable relative urls resolution from GetURL in those cases + warn if no "plugin mode" is activated and relative URLS are encountered.

Votes ? :)

Sandro Santilli <strk>
Group Member
Fri 08 Sep 2006 10:04:22 PM UTC, comment #14: 

It looks as it works just like before (i.e. the same location opens in a new tab). However it maybe because the calculated URL is wrong:

17:51:05: Launching URL... firefox -remote "openurl(http://http/www.voiptalk.org
/products/flash/login.php)"

but it should be http://http/www.voiptalk.org/products/login.php

apparently not the movie location is used as the base URL but the location of the page from which the movie was called.

Also I noticed my browser hangs when I try to leave the page where this movie is. I'm not sure it's related. I'll try tomorrow with an old version and open a new bug if necessary.

Dmitry Panov <dop251>
Fri 08 Sep 2006 02:00:24 PM UTC, comment #13: 

I added parameters passing support in the plugin.
I think it's working, please test yourself.
(I still get X crashes)

Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 05:00:32 PM UTC, comment #12: 

Just as a final summary. We need to find a way to access the PARAM html tags and EMBED tag attributes associated with the movie load.
These will contain FlashVars but also other parameters that we'll send to the standalone player with the -P switch.


Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 03:57:15 PM UTC, comment #11: 

I added a -P switch to the gnash executable.
Manually running this testcase with appropriate -u and -P
switches seems to give good results.

Heres a log produced by hitting all buttons from right to left in order.

17:51:00: get url: target=, url=http://http/www.voiptalk.org/products/flash/login.php (login.php)
17:51:00: Launching URL... firefox -remote "openurl(http://http/www.voiptalk.org
/products/flash/login.php)"
17:51:05: get url: target=, url=http://http/www.voiptalk.org/products/flash/login.php (login.php)
17:51:05: Launching URL... firefox -remote "openurl(http://http/www.voiptalk.org
/products/flash/login.php)"
17:51:11: get url: target=, url=http://http/www.voiptalk.org/products/flash/shop
ping_cart.php (shopping_cart.php)
17:51:11: Launching URL... firefox -remote "openurl(http://http/www.voiptalk.org
/products/flash/shopping_cart.php)"

Next would be having plugin.cpp make up the call.

Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 03:17:21 PM UTC, comment #10: 

Reference about FlashVars:

http://www.permadi.com/tutorial/flashVars/index.html

I'm working on adding a new switch for gnash to support
that. Binding FlashVars to QueryString seems not the correct
approach, so we'd need a separate switch for that.


Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 02:53:05 PM UTC, comment #9: 

I updated gnash to support query strings. At a first look it seems that the SWF file does NOT contain any URL parsing ActionScript code, so this means that we really need a special handling for "FlashVars". I suppose this would be similar to what the ActionScript LoadVars class or the loadVariables global method do, which are also both unimplemented.

Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 12:31:43 PM UTC, comment #8: 

mmm.. we do not pass those vars to the movie.
Can you try simply appending the FlashVars value
to the url after a '?' char and see what happen (with the MM player, that is) ?

I'm trying to figure out the parameters passing mechanism.
My impression is that there's no special support for "parameters"
in the player, and parsing is delegated to ActionScript code inside the movie.

Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 12:12:23 PM UTC, comment #7: 

Hm... I had a look at the html source and it looks like the URLs are passed as parameters:

      <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0" width="785" height="144">
        <param name="movie" value="/products/flash/voip_main.swf"><param name="quality" value="high"><PARAM NAME="FlashVars" VALUE="home_path=index.php&basket_path=shopping_cart.php&account_path=login.php&topup_path=VoIPtalk%2BServices%2FCall%2BCredit">        <embed FlashVars="home_path=index.php&basket_path=shopping_cart.php&account_path=login.php&topup_path=VoIPtalk%2BServices%2FCall%2BCredit" src="./flash/voip_main.swf" quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" width="785" height="144"></embed>
      </object>

So the URL from which the movie is loaded is http://http://www.voiptalk.org/products/flash/voip_main.swf

And the URL that opens when I click "My Account" in IE browser is http://http://www.voiptalk.org/products/login.php

Dmitry Panov <dop251>
Sat 02 Sep 2006 12:00:17 PM UTC, comment #6: 

Ok, I can reproduce the bug. What I'd need next is:
the original url the movie is expected to be loaded from
(to feed to the standalone player with the -u switch)
and the expected url to be loaded.

Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 11:41:10 AM UTC, comment #5: 

If I open it with "gnash -v" I get the following:

15:38:22: Verbose output turned on
15:38:22: OpenGL extension version - 1.3
15:38:22: Got double-buffered visual.
15:38:22: Created top level window
15:38:22: ERROR:   FIXME: tagtype = 25
15:38:22: note: couldn't open cache file 'file:///tmp/voip_main.swf.gsc'
15:38:26: get url: target=, url=file:///tmp/undefined (undefined)
15:38:26: Launching URL... firefox -remote "openurl(file:///tmp/undefined)"


the last 2 lines appear when I click "My Account".

Dmitry Panov <dop251>
Sat 02 Sep 2006 10:45:28 AM UTC, comment #4: 

mm.. I didn't notice that the "relative" url the movie is trying to load is "undefined". So I would expect gnash to reload the same
page... So it seems the problem is with parsing the SWF to extract a correct url. Could you attach the offending movie ?
Also, try opening it with the standalone player with -v.

Sandro Santilli <strk>
Group Member
Sat 02 Sep 2006 10:42:17 AM UTC, comment #3: 

By "the same location" I mean location where the original movie is.

Dmitry Panov <dop251>
Sat 02 Sep 2006 10:40:39 AM UTC, comment #2: 

Now it opens the same location (which is wrong) in a new tab (which is also wrong).

Dmitry Panov <dop251>
Sat 02 Sep 2006 12:56:19 AM UTC, comment #1: 

Should be fixed in CVS, plese give it a try.

Sandro Santilli <strk>
Group Member
Fri 01 Sep 2006 06:33:17 PM UTC, original submission:  

visit http://www.voiptalk.org/
click "My Account" in the top navigation menu (which is flash)
in my firefox it causes a new tab open with location file:///home/dmitry/undefined

Dmitry Panov <dop251>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #10670:  voip_main.swf added by dop251 (33KiB - image/vnd.rn-realflash)

 

Digest:
   task dependencies.

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 19 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-11-17 strk StatusReady For Test Fixed
    Open/ClosedOpen Closed
2006-10-19 strk Dependencies- Depends on task #5919
2006-10-02 strk Open/ClosedClosed Open
2006-10-02 strk StatusFixed Ready For Test
2006-10-01 strk StatusReady For Test Fixed
    Open/ClosedOpen Closed
2006-09-27 strk StatusIn Progress Ready For Test
2006-09-27 strk StatusNone In Progress
2006-09-21 strk StatusWont Fix None
2006-09-19 strk StatusConfirmed Wont Fix
2006-09-09 strk StatusReady For Test Confirmed
    Summaryplugin: FlashVars parameter unsupported plugin: getURL relative urls should be resolved by browser when available
2006-09-08 strk StatusConfirmed Ready For Test
2006-09-02 strk Summaryvoiptalk.org: navigation links don't work plugin: FlashVars parameter unsupported
2006-09-02 strk StatusReady For Test Confirmed
2006-09-02 dop251 Attached File- Added voip_main.swf, #10670
2006-09-02 strk StatusNone Ready For Test
    Assigned toNone strk

Back to the top

Powered by Savane 3.13-3230.
Corresponding source code