Bug 33697 - Unable to choose proxy type "system"
Summary: Unable to choose proxy type "system"
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Options-Dialog
  Show dependency treegraph
Reported: 2011-01-29 12:53 UTC by Laurent Balland
Modified: 2023-02-13 04:52 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:
Regression By:

Proposed patch (951 bytes, patch)
2012-02-22 13:36 UTC, Laurent Balland
Correct patch file (934 bytes, patch)
2012-02-22 13:40 UTC, Laurent Balland

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Balland 2011-01-29 12:53:59 UTC

I was not able to choose Proxy server type "System" from menu Tools > Options > Internet > Proxy
If I change type to "System", then click on OK, when I come back to dialog box, proxy type reverted to previous choice, either "None" or "Manual".

My system is WinXP. Confirmed on Win 7 and Ubuntu 10.10. 
With LibO 3.3.0 RC4.
Same behavior with OOo 3.3.0RC10.
No issue found on IZ.

Good luck.

Laurent BP
Comment 1 Laurent Balland 2011-08-24 13:36:13 UTC Comment hidden (obsolete)
Comment 2 pirri 2012-02-06 10:30:17 UTC

The bug is still present in 3.4.5
Comment 3 Laurent Balland 2012-02-07 01:20:18 UTC

Actually, I did a mistake with my previous test, as the bug is still there. Sorry for the noise :(
To reproduce:
- start with a new profile
- Tools > Options > Internet > Proxy is set to "System"
- change it to "None" or "Manual"
- OK
- reopen Tools > Options > Internet > Proxy
=> setting has been changed, ok
- change it to "System"
- OK
- reopen Tools > Options > Internet > Proxy
Expected: setting should be on "System"
Observed: setting kept previous choice ("None" or "Manual")

Configuration Win7 LibO3.5.0RC3

Work around: 
- either create a new profile
- or manually modify your config file "registrymodifications.xcu" in your profile: 
   - look for "ooInetProxyType"
   - change value between <value> with 1:
<prop oor:name="ooInetProxyType" oor:op="fuse"><value>1</value></prop>

Laurent BP
Comment 4 Laurent Balland 2012-02-22 13:36:35 UTC
Created attachment 57486 [details]
Proposed patch


This patch remove a line preventing the saving of Internet Proxy "System" mode.
It solves the problem described here. Hope it does not have side effects.
Test on OpenSuse 12.1 x86_64.

Laurent BP
Comment 5 Laurent Balland 2012-02-22 13:40:29 UTC
Created attachment 57487 [details]
Correct patch file
Comment 6 Caolán McNamara 2012-02-28 05:38:05 UTC
As far as I can see RestoreConfigDefaults_Impl is supposed to basically do the right thing, reset the values to their defaults, but the cast of m_xConfigurationUpdateAccess to an XPropertyState throws in  SvxProxyTabPage::ReadConfigDefaults_Impl and SvxProxyTabPage::RestoreConfigDefaults_Impl so all of that reset is skipped/non-functional.

Looking into configmgr I don't see any mention of XPropertyState in the list of things an Access supports. Though I do see a mention in (the unbuilt) configmgr/qa/unit/test.cxx of //TODO: support setPropertyToDefault

So either configmgr's Access should support XPropertyState and the existing code in optinet2.cxx would then work fine, or Access shouldn't support XPropertyState and the XPropertyAccess using code in optinet2.cxx is all wrong.
Comment 7 Stephan Bergmann 2012-02-28 11:06:17 UTC
This is kind of funny.  While the old configmgr implementation did support XPropertyState, I was always under the impression that the implementation was actually not functional (i.e., setPropertyToDefault would effectively do nothing), so I did not bother to support it in the new configmgr.

The new configmgr is in since OOo 3.3, btw,; that explains why this issue first appeared with 3.3.

However, the proposed patch will not really work.  As long as no manual settings have ever been made on that options tab page, changing from "None" to "System" will indeed cause the default values for the various proxy settings to be used.  (Which are "external" configuration properties that obtain their values by querying specific "data backends.")  But once any manual settings have been made, changing from "Manual" to "System" will erroneously keep those manual values.

A true fix would require some larger changes to configmgr, so that it keeps around in memory property values from lower layers that are overridden in higher layers.  Other parts of configmgr would benefit from such a change, too (cf. the TODO comment at the head of Components::removeExtensionXcuFile in configmgr/source/components.cxx).  Taking over.
Comment 8 Michael Stahl (allotropia) 2012-07-06 11:06:25 UTC
Comment on attachment 57487 [details]
Correct patch file

according to comment #7 this patch should not be integrated,
setting the "obsolete" flag so it does not turn up in bugzilla queries.
Comment 9 tommy27 2014-11-09 17:04:34 UTC Comment hidden (obsolete)
Comment 10 Stephan Bergmann 2014-11-10 10:10:54 UTC
(In reply to tommy27 from comment #9)
> hi devs, 
> could you please give an update of this REOPENED bug status?
> is this bug still relevant with latest 4.3.3 LibO release

Yes, the analysis in comment 7 is still relevant.
Comment 11 Olivier DANIEL 2016-10-06 12:45:17 UTC

Is this some news about integration of this patch in last release ?
Comment 12 Kaveh 2017-01-18 22:01:09 UTC
This bug has created about 6 years ago and it's not yet fixed in the latest version of LibreOffice (5.2.3), when will a fix be issued for this long-term bug?

I changed proxy settings to manual and couldn't verify if proxy worked, then when I changed it back to "System" proxy, the settings wasn't saved and it still showed the previous settings.
Comment 13 tommy27 2017-01-19 07:23:43 UTC

first of all, learn how to use the bug-tracker...
you changed version field to without reading that it must indicate "earliest affected" (I'm reverting to previous value).

second, this kind of comment won't help fixing the bug.
instead of ranting you can fix it by youself (patch welcome) or pay a developer to fix it.
Comment 14 fvroman 2017-05-04 13:23:50 UTC
Gerrit Patch: https://gerrit.libreoffice.org/#/c/37246/
Comment 15 Xisco Faulí 2017-07-13 10:59:31 UTC Comment hidden (obsolete)
Comment 16 QA Administrators 2019-03-28 04:20:28 UTC Comment hidden (obsolete)
Comment 17 Timur 2019-12-02 14:02:52 UTC
Looks like still true in 6.5+.
Comment 18 Timur 2020-01-17 14:17:33 UTC
*** Bug 130027 has been marked as a duplicate of this bug. ***
Comment 19 Julien Nabet 2020-01-22 16:47:48 UTC
On Win10 with master sources updated today, I could reproduce this, I noticed this on console
warn:cui.options:14416:5208:cui/source/options/optinet2.cxx:304: SvxProxyTabPage::ReadConfigDefaults_Impl: RuntimeException caught
warn:cui.options:14416:5208:cui/source/options/optinet2.cxx:335: SvxProxyTabPage::RestoreConfigDefaults_Impl: RuntimeException caught
Comment 20 Julien Nabet 2020-01-24 09:54:13 UTC
I just read all the comments. The root cause is known but it seems quite complicate to implement (at least for me) => uncc myself.
Comment 21 QA Administrators 2022-11-08 03:48:16 UTC Comment hidden (obsolete)
Comment 22 Laurent Balland 2022-11-19 08:42:35 UTC
Confirmed with Version: (x64) / LibreOffice Community
Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL
Comment 23 sockseight 2022-12-03 06:48:16 UTC
This issue is still seen in LibreOffice

Version: (x64) / LibreOffice Community
Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: en-IN (en_IN); UI: en-US
Calc: threaded

If the proxy setting is set to "None" then LibreOffice connects to the internet directly overriding the system's proxy settings.
Comment 24 Fahad Al-Saidi 2023-02-13 04:52:12 UTC
Looks like still true in 7.5.