Fri 17 Nov 2006 12:21:18 AM UTC, comment #41:
Refer to task #5919 for further discussion
|
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.
|
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à
|
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à
|
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.
|
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 ...
|
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à
|
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)
|
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.
|
Wed 27 Sep 2006 01:22:26 PM UTC, comment #32:
Ok, support complete, voiptalk.org works for me !
|
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 ...
|
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 :((
|
Wed 27 Sep 2006 10:19:59 AM UTC, comment #29:
Seems a good starting point:
http://www.mozilla.org/projects/plugins/npruntime.html
|
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
|
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...
|
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.
|
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.
|
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.
|
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.
|
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 *
|
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.
|
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.
|
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.
|
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.
|
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.
|
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.
|
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 ? :)
|
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.
|
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)
|
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.
|
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.
|
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.
|
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.
|
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.
|
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
|
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.
|
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".
|
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.
|
Sat 02 Sep 2006 10:42:17 AM UTC, comment #3:
By "the same location" I mean location where the original movie is.
|
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).
|
Sat 02 Sep 2006 12:56:19 AM UTC, comment #1:
Should be fixed in CVS, plese give it a try.
|
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
|