GNOME Bugzilla – Bug 644840
Authorization browser window is not be launched if behind a proxy.
Last modified: 2012-06-26 11:12:09 UTC
Just installed frogr 0.4 in Ubuntu Maverick. When first run, frogr show a window so, when clicking in the "OK" button, supposedly, a web browser window is invoked to proceed with the authorization. As I'm behind a proxy, on clicking in the "OK" button nothing happened, just the dialog disappeared. After setting manually my proxy settings in the "Preferences" dialog, I tried to authorize again and, this time, not only the web browser window was opened but also a new dialog appeared. I think, if the proxy is missing, at least a banner notifying about the problem should be shown.
Sure thing. This is indeed a bug and should get fixed, hopefully before the next release is out. Thanks for reporting!
Hi again, I was taking a look to this bug but I'm not able to reproduce it at all. This is what I did: 1. Installed a local proxy for testing purposes only, and configured properly to allow forwarding all HTTP(s) communication through it. 2. Removed my ~/.config/frogr directory, so I have a 'clean' frogr. 3. Start frogr, cancel dialogs, and configure it to use that (local) proxy 4. Close frogr again 5. Performed different tests (T1, T2 and T3): T1. Start frogr, press Ok in the first dialog => the browser opens in the expected page to confirm authorization. The second dialog opens as well. T2. Shutdown the proxy, then repeat steps in T1 => Got an error dialog saying "Connection error: network not available", the browser doesn't open T3. Configured proxy to filter the http://api.flickr.com/services/rest/ URL, then repeat steps in T1 => Got an error dialog saying "Connection error: bad request", the browser doesn't open. Perhaps the error descriptions could be improved, I won't deny that :-), but at least I'm getting errors in all the three cases I've tried so I don't know at this point what exactly your problem was. Perhaps it's not related at all with the proxy configuration but with how the URL is open (frogr should probably start using gtk_show_uri() at some point) Thus, could you please detail a bit more the way to reproduce this? Thanks!
Btw, another helpful thing would be if you could compile it passing --enable-debug to autogen.sh / configure, run it from a terminal and check whether you get some error output there (the debug output is usually more verbose than the GUI) that could help us to better spot the true problem. Thanks again
This problem has been fixed in the development version. The fix will be available in the next major software release. At last, I was able to reproduce it while being on holidays using a very slow/unreliable network connection (aka, my phone's), and it seems the problem was that frogr was actually not handling properly the two HTTP requests performed during the authorization process (get frob & get token), and just trusting them to be fast enough not to notice the problem you described (and that I managed to reproduced exactly in the same way). To fix this, I added extra process dialogs for giving feedback to the user when those asynchronous operations are being performed, and added an extra timeout to properly handle situations when the network is so slow that the authorization process cannot succeed before a reasonable amount of time (which I estimated arbitrarily in 30s, which I think makes sense), reporting such a problem to the user through an error dialog, as suggested in the bug report. Thus, hope it's fixed now. Thank you for your bug report.
I don't know why I cannot reopen. Anyway ... Just checked with frogr_0.6~unreleased-0natty1_amd64.deb Yes, it appears the progress and, yes, after some time it shows a dialog but: 1. You said you set an arbitrary timeout of 30s. Why is so? I don't know which library you are using (most probably libsoup?) but I would say it already uses a timeout for that. I would not tweak it. 2. After the error message, the user is left in the same status than before, the *modal* dialog with the request for authenticate frogr against flickr is shown not letting the user to change the settings if they don't guess that they have to close the modal dialog. I think that's *misleading*. Either: 1. The error dialog suggest actually to change settings and to close the modal dialog. 2. The dialog is not modal. 3. The dialog doesn't appear again. I would go for option 3.
Thanks for taking your time to check this and for providing feedback. See my comments below... (In reply to comment #5) > I don't know why I cannot reopen. Anyway ... > > Just checked with frogr_0.6~unreleased-0natty1_amd64.deb > > Yes, it appears the progress and, yes, after some time it shows a dialog but: > > 1. You said you set an arbitrary timeout of 30s. Why is so? I don't know which > library you are using (most probably libsoup?) but I would say it already uses > a timeout for that. I would not tweak it. Well, after a follow-up commit is actually 60secs now :) #define MAX_AUTH_TIMEOUT 60000 Anyway, I understand your point as "I should not tweak it and rely on libsoup" and I have to say that I almost agree, basically because that was the very first thing I thought of too. However, after some consideration, I realized that for this very specific case (not a lot of traffic required to exchange a couple of strings -aka the auth tokens) it might be handy to set up a "reasonable timeout" (and 60secs looks like a good one to me) while not for other cases (e.g. retrieving the list of tasks, uploading pictures...). So, if I went for changing the timeout in libsoup (which would affect the whole Soup session) down to 60 secs I think that wouldn't be enough for many cases as the exposed above, and if I just did nothing and leave it with the default timeout it could be too much for the case of the authorization process, so that's why I went with this approach. But perhaps you're right and it would be better not to tweak that, not sure though, since I think that it could be intersting that, when in that very special and one-time only step of authorizing frogr, the application didn't look like "stalled" if not able to exchange some few bytes in less than one minute :-) > 2. After the error message, the user is left in the same status than before, > the *modal* dialog with the request for authenticate frogr against flickr is > shown not letting the user to change the settings if they don't guess that they > have to > close the modal dialog. > > I think that's *misleading*. Either: I think it's not. If you get to that state (the auth dialog open again in the first step) after the 60secs period trying to authorize, it could be due to things other than a proxy issue (e.g. temporary extremely slow connection, perhaps via a cell phone), and in that sense maybe just clicking on "Continue" again will fix the issue. > 1. The error dialog suggest actually to change settings and to close the modal > dialog. Could work fine. > 2. The dialog is not modal. Dialogs like this must be modal, IMHO. > 3. The dialog doesn't appear again. I personally would find this more misleading than leaving the issue in the first step to let him/her try again for some more times. If he/she cannot authorize frogr after that, most likely the next obvious step will be to check the network configuration :-) > I would go for option 3. Not sure... I like more option 1 :-) Agree on reopening the bug, at least while we discuss about what should be actually done. My preference: 1st option: I like it like it is now 2nd option: If the MAX_AUTH_TIMEOUT is consumed, suggest the user to check proxy settings. 3rd option: There is no 3rd option for me :)
(In reply to comment #6) ... > Agree on reopening the bug, at least while we discuss about what should be > actually done. My preference: > > 1st option: I like it like it is now > 2nd option: If the MAX_AUTH_TIMEOUT is consumed, suggest the user to check > proxy settings. > 3rd option: There is no 3rd option for me :) ... Really, I think it is misleading to go again to the very same state. I you don't show the dialog again, the user knows that something went wrong, they have in the status bar the message "Not connected to flickr" and they can play with the menu options. Even if the user is damn stupid, they will end closing and reopening, which will show them the dialog again. Current solution would do a stupid user not to know what to do (as they would not understand the error message) and press again in the "OK" button, waiting for another 60secs for the very same error message. My strongly preferred option would be to not show the dialog again. Anyway, in case you don't agree with that, and as the dialog has to be modal, as you said, I would change the used paradigm. Instead of using a dialog, set the whole message about frogr not being authenticated against flickr and the "OK" button as a widget in the background of the application, instead as a separate dialog. This way, the user also can play with the menus, and you still have your very own solution.
(In reply to comment #7) > [...] > Really, I think it is misleading to go again to the very same state. > > I you don't show the dialog again, the user knows that something went wrong, > they have in the status bar the message "Not connected to flickr" and they can > play with the menu options. > > Even if the user is damn stupid, they will end closing and reopening, which > will show them the dialog again. > > Current solution would do a stupid user not to know what to do (as they would > not understand the error message) and press again in the "OK" button, waiting > for another 60secs for the very same error message. > > My strongly preferred option would be to not show the dialog again. Ok, you convinced me :-). Let's do that now then, and maybe will look for a better alternative (showing an specific error dialog, or the option you suggested later in this same comment) for further releases, maybe tracked through a different bug. > Anyway, in case you don't agree with that, and as the dialog has to be modal, > as you said, I would change the used paradigm. Instead of using a dialog, set > the whole message about frogr not being authenticated against flickr and the > "OK" button as a widget in the background of the application, instead as a > separate dialog. This way, the user also can play with the menus, and you > still have your very own solution. I personally prefer not to show the dialog for now, but thanks for the suggestion, we could maybe implement something like that for future releases. Mario
Fixed in master: http://git.gnome.org/browse/frogr/commit/?id=2547f27fd9daacdfebde506368dec74d70a9e6c8 Will see the light with frogr 0.6, hopefully tomorrow in the morning :-)
V.