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

["John Stowers" <john stowers gmail com>]

Hi Cris, thanks for the explanation, comments inline

 

Im not sure I like this change. The hardcoding of the built in web-browser in facebook is intentional - this is because if you make any facebook API calls with the (as yet unauthenticated token) it revokes that tokens validity, which means when the user finishes logging in, Conduits login token token request is denied.

This is similar to what happens with rememberthemilk.  I was playing around with an RTM conduit module and ran into this same problem.

There is a RTM conduit module?? :-)
 

The alternative (which is what the system browser login does) is just to wait a fixed amount of time before checking if the user has logged in. This works OK, but its just a dirty hack - if the user takes too long to log in then Conduit just gives up, because any pending calls will invalidate the token (in the facebook case).

I don't like the arbitrary timeout either.  We don't know when the user grants or denies access when we use the system browser though.  Does the built-in browser solve this problem?

The built in browser is at least detemininstic, i.e. It is guaranteed to block the caller until the user closes the tab that is being used to log in. This means that if authentication fails, it must have been because the user denied conduit access, and not because we called the web sites apis with an unauthenticated token

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!

The only solution that keeps all the code consistent between all dataproviders is to use the conduit web browser. As it happens I think this is actually a better solution, the user gets immediate feedback that the login they are being asked to perform is directly related to Conduit. I havent received any bug reports about Conduit crashing from the built in browser, so I am very tempted (for the next release) to make it the only way to log into websites.

Thoughts?

I submitted the patch because it seems like there's an inconsistency between the built-in property and the browser behavior.

True.  Im not opposed to it completely, it just reminded me of how frustrating the whole webbrowers mess was!

I needed this option to work because gtkmozembed is segfaulting on opensuse11.0 alpha 2 with conduit trunk.   It's segfaulting in libxpcom_core.so during gtkmozembed.MozEmbed().  Running python and doing this manually works fine though.  I don't have a handle on what's going on yet. 

Have you checked the conduit/conduit shell script (i.e. not conduit/conduit.real python code) to check that it finds the run-mozilla script?

see the line

FF_PATH=`ls -d /usr/lib/firefox* | tail -n 1`

is that the correct path on opensuse for ff libs?

The TestWebBrowser dataprovider is useful for testing the built in browser

Interestingly firefox3 gecko1.9 (tested on Ubuntu hardy) finally fixed this problem, no more yucky wrapper script needed!

Let me know if this helps

John

Chris