Re: [PATCH] Don't force gtkmozembed in the Facebook module

[Alexandre <airmind gmail com>]

I like the idea of the external browser, because sometimes the user is already logged in, and only has to authorize or something else. This happens on Flickr for instance.

The only other (crappy) solution, that I can think of, is to run the system browser using a mechanism other than the webbrowser module so we can watch the process and then instruct the user to close the browser instance after they've granted or denied access.

There is no reliable way to create a blocking webbrowser call. I looked for a really really long time into how to do this sensibly, to no avail. webbrowser and xdg-open and gnomevfs all behave differently depending on whether
1) The browser is already running somewhere
2) The user has selected to 'always open new links in tabs'
3) The phase of the moon.

I really hope we can get gtkmoxembed to stop segfaulting, the built in login browser is a lot more pleasant experience!

This is just an idea I got from MusicBrainz. It runs a very small
server on some port (probably an http server), opens the user browser
with a page and the port as a parameter, then that port is called from
within that page. 
For this to work in our situation, it could go into a page hosted in
the Conduit server, or a page served locally from Conduit, showing a
message to close that page after authentication and a frame with the
Facebook login page. Some _javascript_ code could contact the port when
the page is closed to tell Conduit that authentication is over. There
are drawbacks, but could be a workaround. 
Maybe security could be an issue here, because this page could be hijacked and the login information stolen by someone else.
What do you think?

-- 
Alexandre Rosenfeld 

EngComp 06 - USP São Carlos