Tue 09 Nov 2010 07:21:38 AM UTC, comment #19:
Support added in release 0.8.8
Requires newer NPAPI and uses NPN_GetValueForURL (xpcom-less)
|
Sat 20 Mar 2010 10:35:48 PM UTC, comment #18:
Something to look at for an xpcom-less implementation:
https://developer.mozilla.org/en/NPN_GetValueForURL
|
Tue 07 Oct 2008 03:53:37 AM UTC, comment #17:
Good information here:
http://www.nabble.com/Status-update-for-xulrunner-1.9---maintainers,-we-need-you-td17016379.html
|
Mon 06 Oct 2008 05:17:33 PM UTC, comment #16:
So, I committed the latest patch, fixed umask but disabled (#if 0)
the actual dump of cookie files.
Whats needed:
- Appropriate unlink of the file on exit
- Setting GNASH_COOKIES_IN environment variable in the spawned standalone process environment
- Readability cleanups
Nelson: please test any XPI issue.
|
Mon 06 Oct 2008 03:11:56 PM UTC, comment #15:
We should assume that if somebody does have xulrunner 1.8 installed, Gnash's new xpcom support should still configure, compile, and run. We don't necessarily care how they get xulrunner 1.8, but if they did, it should work.
|
Mon 06 Oct 2008 03:08:55 PM UTC, comment #14:
Usable 1.8 glue doesn't exist in a package for Ubuntu or Debian.
Now, it's possible that we can compile by forcing people to download the entire Firefox source code, compiling it to get the 1.8 glue, and then using that at runtime. Is that better than requiring 1.9 for Ubuntu and Debian?
Fedora (Mandriva, SuSE, etc) are a different matter and must be dealt with individually.
|
Mon 06 Oct 2008 02:26:48 PM UTC, comment #13:
We don't want to insist on xulrunner 1.9.
|
Mon 06 Oct 2008 01:12:27 PM UTC, comment #12:
So, it seems we're asking for xulrunner-dev version 1.9 for now.
Dunno how much the macro enforces this, but that's what ./configure
asks the user to install.
asac: Does it do for the run-time check ? And do you plan to work on the features requested in comment #9 ?
|
Fri 19 Sep 2008 03:11:58 PM UTC, comment #11:
Assigning this to nelson as he's also working on XPI support which would need XPCOM for finding user profile path.
|
Mon 09 Jun 2008 10:35:25 AM UTC, comment #10:
a short note: run-time check for xpcom wont be really possible.
If we use the 1.8 glue it should work almost everywhere though.
|
Mon 02 Jun 2008 09:17:26 PM UTC, comment #9:
Requests for improvements:
- umask should be 0066 (not 0600)
- the cookie file creation code should be in its own function
- the cookie filename should include pid of standalone player, and possibly 'gnash' prefix
- cookie file must be removed when the standalone exits (maybe could be uses for output as well, should be safe already)
- configure shouldn't bail out if xpcom isn't available
- the plugin shouldn't refuse to work if xpcom isn't available (run-time check)
|
Mon 02 Jun 2008 07:15:58 PM UTC, comment #8:
Yes, GNASH_COOKIES_IN should be enough to make your case work.
For the testcase I was thinking of a public case...
|
Mon 02 Jun 2008 07:12:37 PM UTC, comment #7:
I read from tmpnam man page:
Portable applications that use threads cannot call tmpnam() with NULL parameter if either _POSIX_THREADS or _POSIX_THREAD_SAFE_FUNCTIONS is defined.
I guess you could use pid of forked process, or
pid of the plugin process and a counter.
|
Mon 02 Jun 2008 07:11:11 PM UTC, comment #6:
If we have the complete implementation i can test it with the ubuntu online course - which initially caught my attention on this.
Is it supposed to work if I only provide a filename for IN cookies?
|
Mon 02 Jun 2008 06:59:23 PM UTC, comment #5:
BTW, do you have any online testcase to verify the implementation
works (or doesn't) ?
|
Mon 02 Jun 2008 06:58:36 PM UTC, comment #4:
The env variable is GNASH_COOKIES_IN for input
and GNASH_COOKIES_OUT for output.
Running with -vv should tell you when import/output
is attempted (grep cookies).
You can also set verbosity 2 in your ~/.gnashpluginrc
if you want to avoid adding the -vv to process invocation.
|
Mon 02 Jun 2008 09:57:32 AM UTC, comment #3:
ok, this is now done. The file is dumped into cookiesfile; how you couple that with the forked process is your decision.
The environment thing didn't work for me ... so I left that alone. Maybe that was just because I didn't get gnash dump any debug messages from within the forked process.
I would vouch for adding a real command line option for passing a cookies file instead of this COOKIES_FILE_IN environment.
Let me know if you need more infos.
(file #15782)
|
Fri 30 May 2008 01:19:20 PM UTC, comment #2:
ah ... to test the build you need xulrunner-1.9-dev installed atm. We can look into how to support upstream SDK builds and other distributions once this flies.
|
Fri 30 May 2008 01:18:29 PM UTC, comment #1:
the current patch does everything except actually creating the tmpfile and writing the cookies to it.
The while loop iterates through all cookies, so it should be straigt forward to go on from here.
Will follow-up if noone else finishes it :).
|
Fri 30 May 2008 01:15:45 PM UTC, original submission:
As discussed, the idea is to dump a cookies.txt file before forking gnash and use that inside of gnash to give curl the proper cookies.
|