I've just been beaten by this problem and it took me two good hours to sort out
why app manager was not working and I ended up reinventing your workaround
(delete connection and recreate it).

It was with latest 2007.10 OS, steps to reproduce:

1. disconnect
2. add a unexisting proxy to your connection setting (host=toto, port=1 for
http) with connection manager
3. connect
4. check web => doesnt work as planned, error about proxy
5. disconnect
6. uncheck the proxy in your connection setting
7. reconnect
8. check web => it works as planned
9. try app manager tools refresh => you get an error pop up => BAD
10. look app manager tools log, you see it's using still using "toto" host
11. type in xterm:
$ gconftool-2 -R /system/http_proxy
 use_http_proxy = true
 use_authentication = false
 host = toto
 ignore_hosts = []
 authentication_user = 
 authentication_password = 
 port = 1

I assume the connection manager check "use_http_proxy" and it's still true.

To fix I assume either change the connection manager behaviour to clean
use_http_proxy in case the proxy checkbox is unchecked, or change the
application manager to read proxy settings like the web browser (or both :).

Confirmed on OS2007 2.2006.51-6.

However, there's no need to delete the connection to get the Application Manager
working again.

Just edit the connection in Connection Manager and in the "advanced" section:
o tick the proxy-enable box
o delete the proxy IP
o set the port to 0
o untick the proxy-enable box

Those steps worked immediately here.  No need to recreate the connection at all.

Created an attachment (id=710) [details]
Copy of gconf dump and current prefs.js

This bug is still present in the latest release of the OS
(RX-34_2008SE_2.2007.50-2).  I noticed it because a connection that uses a
proxy "contaminated" the other connection I had defined.  The proxy settings
for the proxy-using connection will always be written to prefs.js, regardless
of which connection is chosen.  Using gconftool to dump the connection settings
show the correct values; the connection manager does so as well.  I've attached
the complete gconftool dump for the device as well as a copy of the resulting
prefs.js.  The solutions given earlier do nothing because the problem is not
that the proxy values are incorrect (excluding microb prefs.js), but that the
wrong connection settings are being written to prefs.js.

Withdrawing my vote for the bug-- my mistake!  I set the http_proxy environment
variable in the ~user/.profile.  With that gone everything works perfectly,
sorry for the confusion.

Comment 6 Andre Klapper 2008-10-08 18:01:14 UTC

*** Bug 3110 has been marked as a duplicate of this bug. ***

Confirming that this bug is still present in 4.2008.36-5

Comment 8 Andre Klapper 2008-10-20 11:18:58 UTC

Matt: Does Larry's workaround (comment 5) work for you?

I don't have http_proxy set in my ~/.profile. Leaving the port set to non-zero
doesn't seem to be a problem, it's only the proxy hostname that App Manager
seems to be looking at.

App manager needs to be restarted to get it to notice changes in the server
name field.

Comment 10 Patrik Flykt 2008-11-06 11:27:31 UTC

(In reply to comment #7)
> Confirming that this bug is still present in 4.2008.36-5

Can you give the scripts /etc/network/if-up/00_proxy_set and
/etc/network/if-post-down.d/zz_proxy_unset a look and figure out what might be
wrong?

(In reply to comment #10)
> Can you give the scripts /etc/network/if-up/00_proxy_set and
> /etc/network/if-post-down.d/zz_proxy_unset a look and figure out what might be
> wrong?

In proxy_set, it does:

set_use         `read_proxy proxy_http`                              

set_use() does:

        if test x$1 = x                                         
        then                                                         
                gconf_unset="$gconf_unset -u $key"             
        else                                                        
                gconftool-2 -s $key -t bool TRUE         
        fi                                           

It shouldn't be testing http_proxy (that's the proxy host itself), I think it
should be looking at the osso "proxytype" key instead?

Offtopic, testing this stuff reminds me how bad the network connection UI is
:-\

Comment 12 Quim Gil 2009-05-18 23:03:07 UTC

Andre, it would be good to check this with the testers of the Fremantle AM. The
code of the application hasn't changed much from Diablo, so if there was a bug
there I wouldn't be surprised if it still exists.

Comment 13 Andre Klapper 2009-07-14 16:03:24 UTC

DIABLO 5.2008.43-7:
1. Set up some fake proxy in Connection Settings > Advanced
2. In Terminal, run "gconftool-2 --get /system/proxy/mode". Get "manual".
3. Go to Connection Settings > Advanced
4. Disable "Use proxy"
5. In Terminal, run "gconftool-2 --get /system/proxy/mode". Still get "manual".
Wrong.


Current Fremantle:
1. Set up some fake proxy in Connection Settings > Advanced
2. In Terminal, run "gconftool-2 --get /system/proxy/mode". Get "manual".
3. Go to Connection Settings > Advanced
4. Disable "Use proxy"
5. In Terminal, run "gconftool-2 --get /system/proxy/mode". Get "none".
Correct.

Comment 14 Andre Klapper 2009-07-14 16:35:14 UTC

Still happening in latest Fremantle.
As the gconf key now gets updated correctly (compared to Diablo; see my last
comment) I consider this to be an application issue.

ACTUAL OUTCOME:
   "Application list partially refreshed.
    Some catalogues unavailable.
    Check catalogue details."
Click "Details" and click "Fremantle", result:
   "http://repository.maemo.org/extras-devel/dists/fremantle/Release.gpg
    Could not resolve 'example.foo'"

EXPECTED OUTCOME:
Ignore the *disabled* proxy and work correctly.

Comment 15 Andre Klapper 2009-07-29 18:52:09 UTC

This issue has been FIXED in the internal Fremantle version.

Unfortunately this is a WONTFIX for Diablo as Diablo is in maintenance mode and
Nokia will only provide bugfixes for critical issues if at all.
For your interest the Mer project aims to provide a community backport of
Fremantle for N8x0 devices. See http://wiki.maemo.org/Mer for more information.

Verified in 1.2009.41-10 :-)