Bug 295065 - Change in proxy settings breaks Chromium's settings
Summary: Change in proxy settings breaks Chromium's settings
Status: RESOLVED INTENTIONAL
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_proxy (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR minor
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-29 12:52 UTC by Bernhard Jungk
Modified: 2012-06-14 00:42 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernhard Jungk 2012-02-29 12:52:05 UTC
Version:           unspecified (using KDE 4.8.0) 
OS:                Linux

Since KDE 4.8 Chromium doesn't recognize the proxy settings anymore. An earlier bug was filed, describing the problem, but was closed as invalid:

https://bugs.kde.org/show_bug.cgi?id=288002

The bug is caused by a change of KDE's behavior as shown in the corresponding Chromium bug. The KDE proxy settings format changed, omitting a ":" in kioslaverc (comment #6):

http://code.google.com/p/chromium/issues/detail?id=106052

Is this change intentional? It is a change which is very counter-intuitive to the usual usage of e.g. the http_proxy environment variable. I suggest the best fix for this problem would be to revert to the old behavior, unless there are significant technical reasons for the new one, of course.

Reproducible: Always

Steps to Reproduce:
Change the proxy settings to a manual setting.

Actual Results:  
Unable to use the proxy.

Expected Results:  
Surfing the web via proxy.
Comment 1 Dawit Alemayehu 2012-06-14 00:42:51 UTC
Sorry but this is really not a KDE problem since we reserve the right to change our configuration files at any time. If an external application was relying on reading our configuration file, then they need to update their code every time we make such a change. We cannot be held hostage to 3rd party applications reading application specific configuration file when we provide an API to insulate against such issues.  
Moreover, there was a legitimate internal technical reason why we switched over to using a white-space instead of a colon to separate the port# from the actual proxy address..

Anyhow, they have already fixed this in Chrome as can be seen from the bug report you listed above ; so closing this as a WONT FIX.