Hello, 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
Solve in LibO 3.4.2
Hi, The bug is still present in 3.4.5
Hello, 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
Created attachment 57486 [details] Proposed patch Hello, 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
Created attachment 57487 [details] Correct patch file
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.
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 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.
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
(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.
Hi, Is this some news about integration of this patch in last release ?
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.
@Kaveh first of all, learn how to use the bug-tracker... you changed version field to 5.2.3.3 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.
Gerrit Patch: https://gerrit.libreoffice.org/#/c/37246/
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Looks like still true in 6.5+.
*** Bug 130027 has been marked as a duplicate of this bug. ***
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
I just read all the comments. The root cause is known but it seems quite complicate to implement (at least for me) => uncc myself.
Dear Laurent BP, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Confirmed with Version: 7.4.1.2 (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
This issue is still seen in LibreOffice 7.4.3.2 Version: 7.4.3.2 (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.
Looks like still true in 7.5.