Synced settings lost on new version

[ldumlija]

Hi,

extension updated to latest version and I lost all my settings synced over google account on chrome.

Can you please tell me is there any way I can recover my settings? I tried to enable/disable sync, but list is still empty.

FoxyProxy version: 8.1

Chrome is up to date Version 119.0.6045.199 (Official Build) (arm64)

[erosman]

Sync is used when data is shared between 2 Chrome browsers. Do you have the data in another Chrome browser? If so, you can export fr0m that Chrome and import into this one.

You can also import settings if you have a back-up of FoxyProxy v3 settings.

[ldumlija]

On all devices extension is automatically updated to newest version (that happened before I realised i lost configuration). Where can I find previous version of chrome extension so I could try to install older version and view if old config shows up?

Also, I don't have backup because backup feature never worked for me in chrome.

[erosman]

Where can I find previous version of chrome extension so I could try to install older version and view if old config shows up?

Try https://chrome-stats.com/d/gcknhkkoolaabfmlnjonogaaifnjlfnp/download

[ldumlija]

Im just able to download current version.

Older version from git (https://github.com/foxyproxy/Foxyproxy_Chrome/releases/tag/standard-3.0.7.1) chrome cant load..

[erosman]

Try this and let me know the result...

1. Go to the Options page
2. Open the Dev Tools (F12)
3. Go to the Console tab
4. Type the following and hit ENTER

browser.storage.sync.get().then(console.log) 

If above has some data, then in the Console tab

1. Type the following and hit ENTER

browser.storage.sync.get().then(pref => {
  const data = JSON.stringify(pref, null, 2);
  const blob = new Blob([data], {type: 'application/json'});
  browser.downloads.download({
    url: URL.createObjectURL(blob),
    filename: 'FoxyProxy_sync.json',
    saveAs: true,
    conflictAction: 'uniquify'
  })
  .catch(() => {}); 
});

2. Go to Import Tab -> Import from older versions
3. Import FoxyProxy_sync.json file that you have saved
4. Click SAVE to save the data

[erosman]

Someone else has posted that:

Good, I'm waiting for this release. And it seems I understood why my proxy configurations disappeared today: for the first time in history, I enabled synchronization with a Google account by selecting the "Sync settings with Google" option in the FoxyProxy settings. But when I disabled this setting and restarted the browser, my old configuration thankfully came back.

[Doc73]

Same issue from me. I solved it by importing the proxies settings from Firefox.

[erosman]

We have worked on a fix and we are uploading v8.2 which would hopefully fix the issue.

[ldumlija]

Is there only one FoxyProxy listed under chrome://extensions/? If that is the case, then installing an older version probably wont help.

Try this and let me know the result...

1. Go to the Options page
2. Open the Dev Tools (F12)
3. Go to the Console tab
4. Type the following and hit ENTER

chrome.storage.sync.get().then(console.log) 

If above has some data then in Console tab

1. Type the following and hit ENTER

browser.storage.sync.get().then(pref => {
  const data = JSON.stringify(pref, null, 2);
  const blob = new Blob([data], {type: 'application/json'});
  browser.downloads.download({
    url: URL.createObjectURL(blob),
    filename: 'FoxyProxy_sync.json',
    saveAs: true,
    conflictAction: 'uniquify'
  })
  .catch(() => {}); 
});

2. Go to Import Tab -> Import from older versions
3. Import FoxyProxy_sync.json file that you have saved

I was able to recover my settings with this method. Thanks a lot!

[nerux1]

Try this and let me know the result...

1. Go to the Options page

2. Open the Dev Tools (F12)

3. Go to the Console tab

4. Type the following and hit ENTER

browser.storage.sync.get().then(console.log) 

If above has some data, then in the Console tab

1. Type the following and hit ENTER

browser.storage.sync.get().then(pref => {
  const data = JSON.stringify(pref, null, 2);
  const blob = new Blob([data], {type: 'application/json'});
  browser.downloads.download({
    url: URL.createObjectURL(blob),
    filename: 'FoxyProxy_sync.json',
    saveAs: true,
    conflictAction: 'uniquify'
  })
  .catch(() => {}); 
});

2. Go to Import Tab -> Import from older versions

3. Import `FoxyProxy_sync.json` file that you have saved

4. Click SAVE to save the data

It works fine, thanks a lot.

[gjaekel]

https://github.com/foxyproxy/browser-extension/issues/45#issuecomment-1840483367 works for me, too.

[dazwu]

HI! I only use foxyproxy on Firefox. After Upgrade all settings were gone. Switchback to old version broke everything else what could ever have been a config. Removed Foxproxy for now. how can i extract the config from a backup? I did never export the settings manually. Where does foxyproxy store its settings? i also would like to have the newer version but the proxy list was looong. ( working w/o Problems with foxproxy for 6+ Years now)

[sbakker]

Same here. Cannot find any proxy settings in my profile directory.

[sebix]

For recovering the settings, see https://github.com/foxyproxy/browser-extension/issues/45#issuecomment-1838719332 Keep in mind that "Go to the Options page" actually means opening the FoxyProxy configuration page by eiterh

• Open the AddOns Manager (about:addons)
• Search for FoxyProxy, three-dot-button -> Preferences

or

• open FoxyProxy with the icon right of the address bar
• Options

Then proceed with the console. That worked for me.

[erosman]

I have updated the Read Me of the repo with methods to retrieve data (Sync and local).

https://github.com/foxyproxy/browser-extension

[dazwu]

HI - reset my whole Firefox profile - disabled Sync. Updated Foxyproxy. Now all works as designed!

I stupidly removed the extension when trying to get it to run so the local settings were removed too. Thx for help!

[sbakker]

@sebix wrote:

Keep in mind that "Go to the Options page" actually means opening the FoxyProxy configuration page by eiterh

Ah, silly me. I didn't read that properly initially. Thanks for clarifying. Things are running fine again. 👍

@erosman - thank you for all your efforts. FoxyProxy is always either the first or the second (after PrivacyBadger) extension that I enable on fresh installs.

[rockpi4]

All settings are lost, by trying to repair it, old was imported, sync was acitve and now all settings are gone without possibility to revert it or at least do it in simpler way than writing from scratch. This is not acceptable, I am using foxyproxy since over 10 years and a lot of tunnels which I did use for work too. I read one of first replies from Eric Young where he replies to always coming criticism about ads by pretty uncool answer to go to google and see if they do anything against those who maintain. Eric also claims to pick it up on him. Well, I'll do it.

Eric, I am like many other who use your extension, developer in our main jobs. One who works as developer does not need to have explained how bad it is to release destructive code. As a developer, one is asked about competences to which one could consider proper testing and no hush hush releases to millions of users, in my world it is called irresponsible. This issue costed not only me time for nothing, but time from other people too and you as a developer of it can not be professional enough to act polite and nice towards those who use your work? Maybe I am wrong, but I feel at the same time arrogance and frustration.

I can not rely on foxyproxy and as I see its developer asks other people to ask google why their data was destroyed. I will not use it anymore and there are anyway better solutions where one will not be put into situation to ask publicly about developers competences.

Thank you for providing this extension for many years, I used it and recommended with pleasure. Nothing lasts forever and things break, I am sad to witness it.

[erosman]

All settings are lost...

@rockpi4 Didn't the recovery methods on https://github.com/foxyproxy/browser-extension help?

[rockpi4]

@erosman thanks for reply, I see that there might be ways, I was able to overwrite the old from may backup, but since may I changed a bunch of my socks ports which I did not backup as I did it last week. I can not waste time to check which version from which date was ok, all of this causes problems, since yesterday I lost 24 hours on rewriting all of them just to come here and read reply from Eric which caused frustration in me as I wasted time to rewrite it because I can not rely on it and it can happen again in a week where Eric will not provide support but send me to google. If I write the issue, I see already one dislike and it is again not Eric who tries to help. So, there is no other way than moving to a secure, stable solution and there are plenty of them. Only time prevented me from switching to it since foxyproxy did not work on chrome based browsers as expected. Time has come it seems.

Thank you anyway for trying to help, yes I've read it and it is no solution for me.

[erosman]

@rockpi4 I am very sorry for the inconvenience caused.

There were undiscovered bugs in the migration of the old data to the new format that affected some users (mostly they users that had sync enabled).

FoxyProxy 8 was re-written from the ground up due to the changes introduced by Google in manifest v3. The new code has been available on repo for nearly 2 years for beta testing.

FoxyProxy Basic v8.0 (same code) (26k users) was released in September but unfortunately we didn't get any reports of the above bug, otherwise we would have fixed it before releasing the Standard version.

[rockpi4]

@erosman thanks for further information. I never claimed that there is bug free software, but when you do have a sync part in your code, then one has to ensure that there is at least a valid backup of settings. Now even more questions arise on my side at least. As example, is there any other possible way that this bug was undiscovered if updating just a few clients should have resulted in bug reproduction? I witnessed many going live going wrong due to silly bugs, important was then how situation is handled. But to not see a bug which destroys all settings by simple sync process means to me at least that sync was not tested before it was released. If Eric would have replied something like "Sorry, by mistake we clicked release button and we already work on solutions" then I would probably have not lost my faith in this code.

[gjaekel]

rockpi4: This issue costed not only me time for nothing, ...

You also have payed nothing to take hours of time of erosman. For many years, as you wrote. Within the time you spend to write down your epic flames here, a well-skilled person like you should be able to restore the data.

[rockpi4]

@gjaekel Guido, how do you know if I ever paid or not or how I supported this project? Your post is offtopic and of provocative nature, please refrain from it.

[rockpi4]

@erosman why is there cost free version available and why do you work on it as well why do you reply in tickets/issues if other members here claim that your time is too valuable for being spent on this project. Does anybody force you to reply or to do any work? Did @gjaekel mean that "basic" versions can include destructive code as well as it is ok that the code is not tested. If so, then you maybe should list next to differences in features also differences of your code developments, roadmaps, .... . :), I think you maybe should inform better your users about why you waste your valuable time. Interesting is, people cheerleading never consider that only user lost its time as it is mostly free time used for it.

[rockpi4]

@erosman by the way, this is not the only bug of this new version, there are several more and one would need to inspect them, as example socks does not work anymore as it did before, local networks can not be reached, dns issues and probably much more. This should have never been released and your beta participation is obviously with flaws and has potential to get better. I will not inspect more or open issues anymore, I wasted enough time and already switched to better (for me) solution which does not involve extensions or third party service. Thanks for your support and I wish you and foxyproxy good luck for future.

[erosman]

local networks can not be reached

FoxyProxy 8.0-8.3 on Firefox had localhost, private local network pass-through matching Chrome & Firefox policy. The localhost, private local network pass-through was reverted in v8.4 on Firefox. Check About for more information.

dns issues

DNS is handled by the browser.

[rockpi4]

FoxyProxy 8.0-8.4 on Firefox had localhost, private local network pass-through matching Chrome & Firefox policy. The localhost, private local network pass-through was reverted in v8.4 on Firefox. Check About for more information.

Well, to version 8 it was autoupdated without telling me about any changes or known bugs. Somehow I do not understand if private local network pass-through was meant to break functionality and that it was somehow communicated? If yes, then I do not remember ever getting any notification about it as well as release notes which clearly identify problems of changing like that local networks can not be reached due to change .... Where was it? I read all release notes and it was nowhere explicitly mentioned. Then you say you reverted it with 8.4, again without to notify users properly why it was reverted. Considering the fact that it was reverted for some reason, it looks like that path was wrong and versions 8.0-8.4 should not have this change implemented, however, you mentioned it being beta part with 26k testers which obviously failed to argument during 8.0-8.4.

I just updated to latest version for ability to confirm your (and my) statements. As first, under release notes only this can be seen: Fixed an issue with migrating database from older versions (#69) Updated user interface to disable inapplicable options in proxies (#52) Updated wildcard to regular expression conversion (#72)

I am not sure, I guess my autoupdated version was 8.2 before I upgraded and my points for that version are valid. 8.4 will also not revert lost settings as they are lost and overwritten due to developers not testing before releasing into the wild.

I am not sure what you meant by DNS is handled by browser, this is broad answer, my point was that there were DNS issues when extension is on, this behaviour is also gone with version which I installed for ability to test your statement. I also told that I did not inspect in details any of those issues, you already confirmed one in a cryptic way which normal joe will not understand, its ok.

All in all, my settings are still gone and I have no time anymore to deal with those issues, I have to rely on working code without unwanted updates which destroy data, I did not expect this team to commit such a mistake, bugs are acceptable but this is something that forced me to change working system (for 10 years) to another solution because all my work was gone and I was proven that this way of development is not reliable to be used, especially if data is lost.

Hope you can make something positive out of my comments, I see that you have at least one eager user downvoting all my posts which is clear abuse of githubs policy as tools provided are not used properly. Maybe this is one of reasons why 26k beta testers over a quite long period of time were not capable finding such an epic bug which will simply force many people to look for any other just reliable solution. On that point a question begs to be asked what are the requirements for beta testers and if this information should be actually part of feature description as obviously it matters if beta testers are all just normal users or are there some mature developers too. However, I am not eager to get into that discussion, hope you can make the best of this fiasco.

[erosman]

release notes which clearly identify problems of changing like that local networks can not be reached due to change

Local networks can be reached. They were set not to be proxied as proxying localhost/local network can pose a security risk. The Help explains the process with references to the Chrome & Firefox polices. The users who requested it, had the proxy server and the target all within the local private network. That applies to a very select group of users who want to access some page on their local private network via a proxy set within the same local private network.

again without to notify users properly why it was reverted. Considering the fact that it was reverted for some reason

Notification is in the release notes and changelog with reference to the posts about it.

I am not sure what you meant by DNS is handled by browser, this is broad answer, my point was that there were DNS issues when extension is on

DNS is not handled by FoxyProxy and any issue with DNS is not related to FoxyProxy.

On that point a question begs to be asked what are the requirements for beta testers and if this information should be actually part of feature description as obviously it matters if beta testers are all just normal users or are there some mature developers too.

They are not beta testers. They are normal users.

FoxyProxy Basic which has the same code as FoxyProxy standard was released in September. FoxyProxy Basic has 26,000 users. We waited for 2 months for bug reports and feedback, before releasing FoxyProxy standard. We didn't get any bug reports about the database migrate issue. If we had received a bug report, like what we got when FoxyProxy Standard was released, we would have surely fixed it.

The issues posted in the repo can be inspected for verification.

[rockpi4]

They were set not to be proxied as proxying localhost/local network can pose a security risk. Is it a threat or a feature especially if it is used this way. I do require to access local networks of my reverse ssh connections, 10 years ago exactly that was the purpose for use of foxyproxy it as it looks, v8.0-v8.4 were unusable for me.

The users who requested it, had the proxy server and the target all within the local private network. I often ask my son if he would jump from a building if his friends come to such idea. Obviously, what users requested would break functionality of many other users who are indifferent to what a group of requester want. I am not part of your team and can not know why few requests force you to break a system which for me at least until recently was "never change a working system". Beside all of that, it seems that you either did not have enough time or simply resources (like HR) to properly evaluate this change and maybe simply make it switchable as feature. Anyway, you went for something that has been reverted with latest version and in no sentence you explain why it was reverted as maybe our discussion about it is already obsolete (for me at least)?

DNS is not handled by FoxyProxy and any issue with DNS is not related to FoxyProxy. If local networks can not be reached, then dns with local ip of that network can not be reached too. This is 100% related to Foxyproxy and is caused by changes which you mentioned 8.0-8.4. At the time of posting I did not have information that you known about those bugs and that DNS issues were connected to the same issue, which was to break working code on request on who knows how many people and who knows for which purpose (as it was reverted).

They are not beta testers. They are normal users. I understood wrongly one of your replies, I am sorry for this confusion.

We waited for 2 months for bug reports and feedback, before releasing FoxyProxy standard. Obviously waiting was not a problem, you could have waited for 6 months and then release it and break everything. Please do not wrongly understand me. If you do not have beta testers, then you probably should think about having some. If such obvious bug was not detected for such a long time, then you have to add other possibilities why it happened.

[erosman]

Anyway, you went for something that has been reverted with latest version and in no sentence you explain why it was reverted

It was reverted to match v7.* behaviour due to user requests in this repository, as referenced by the issue numbers.

If local networks can not be reached,...

Local network were always reachable. They were not proxyable in v8.0-8.3.

DNS (domain name system) is a function performed by the browser to convert domain names to IP numbers. FoxyProxy has no hand in the process.

If you do not have beta testers, then you probably should think about having some.

Software are released regularly by major companies with 1000s of employees, developers, testers. Don't MacOS, Windows, Linux distros, Android etc have bugs? Even software that charge $100s have bugs.

The bugs in the FoxyProxy, while inconvenient, didn't destroy user data. User data was untouched. Due to the bug it was not imported. Many users have successfully recovered their not-imported data with the methods listed on the front page.

[rockpi4]

It was reverted to match v7.* behaviour due to user requests in this repository, as referenced by the issue numbers. Thanks for clarification. I do not want to annoy, but this must be another group requesting something different than the group which insisted on this change? Just wondering how experimentation with feature requests works out in this project.

`Local network were always reachable. They were not proxyable in v8.0-8.3.

DNS (domain name system) is a function performed by the browser to convert domain names to IP numbers. FoxyProxy has no hand in the process.`

I develop and used to run sometimes some tests using browser, reports that dns is not reachable did let me assume that issue has to do with recent update. I did not attribute it to the same bug which probably like I stated caused some other issues, especially since I faced issues and troubles withing seconds and realized few things not working, I am not sure if you attribute DNS issue to my expression in english.

Local network were always reachable. They were not proxyable in v8.0-8.3. I am actually already lost if what was and what was not possible, simply put, socks5 servers do not work since the update which destroyed my configs.

The bugs in the FoxyProxy, while inconvenient, didn't destroy user data. User data was untouched. Due to the bug it was not imported. Now I find exactly this inappropriate from you. You play with terminology and after admitting to have bug which caused people to lose their configs, you do claim now that their configs and files is not their data. All of that after you released something that was neither properly tested nor you show understanding for people loosing their data.

Many users have successfully recovered their not-imported data with the methods listed on the [front page](https://github.com/foxyproxy/browser-extension). Your solution to run code in console is for sure not to be seen as solution, as from normal joe is probably better not to open console at all as some will not even be able to overcome first warning. Secondly, all of this happened during development phase where ports were changed and for some time it was not clear why nothing works, old backup, fresh configs etc... . Old configs are lost by that as default recommendation next to browser cache, cookies etc.. is to reset to defaults.

Beside all of that, you posted your solution already after old data was overwritten and your method simply retrieves current config. As I mentioned in first post, I do not trust sync and online sync developments exactly because of such things and do regular backups of my configs, however, you released it at the time where I was applying changes to socks servers.

Now if you develop on many projects and you used foxyproxy for testing your code, then you are suddenly screwed and your projects on hold. That is the result in my case at least. I though it helps expressing my experience, but I see that you are not willing to view all of this from different angle.

Thanks anyway.

[erosman]

I am actually already lost if what was and what was not possible, simply put, socks5 servers do not work since the update which destroyed my configs.

Setting SOCKS5 servers works fine and worked fine in v8.

Setting SOCKS5 proxy (or any other proxy) and then setting FoxyProxy to open localhost by first going to the SOCKS5 server and back to your localhost was prevented.

That is the standard behaviour in Chrome & Firefox, if you set proxies directly in their configuration.

Now I find exactly this inappropriate from you. You play with terminology and after admitting to have bug which caused people to lose their configs, you do claim now that their configs and files is not their data.

That is not what I meant. What I meant was that the data is recoverable.

[rockpi4]

That is not what I meant.

That is why I say that you play with terminology, you expressed that nothing is lost which is not truth as well as you claim right next something which is not truth.

What I meant was that the data is recoverable.

You do play again with terminology. You obviously state knowingly something that is not truth, please look in dictionary what it means. Secondly, data is not recoverable, your extension gives a user no possibility to retrieve "Lost" data which you point as solution. When you have enabled this function in your extension, then you might claim that there is a function retrieving your locally stored config which your buggy version failed to process due to database issue, but not as solution.

You see, of course is data recoverable in broad meaning, as example a user has to write it from scratch.

What you posted is even not to be called a solution, this is slightly just a workaround to get local config in case it is not lost by previous attempts to recover it and nothing more, there is no solution and no possibility to recover lost data.

You are from US, english is probably your first language and your project runs since almost 20 years. It is hard for me to believe that you do not understand that data is not recoverable and stating it that way in current case is playing with terminology to express something which does not reflect the reality, I do dislike when developers start moving their fault to everybody else.

[erosman]

We are sorry for the incontinence caused.

[c0xc]

Setting SOCKS5 servers works fine and worked fine in v8.

It didn't work for me and those who commented in bug report #70 so I had to downgrade and disable updates.

[rockpi4]

@c0xc exactly, the only real workaround is a downgrade, but a warning here too, because if you upgraded, then downgrade will cause issues where extension will not work properly and if you check patterns, you will see nothing, deleting all proxies and importing v6-v7 config works then.

By that, the only real solution is to downgrade, those online published versions should have been taken down, all v8.

Just to mention another issue with v8 on firefox on linux, leaving firefox open for some time connections work, but at some point no connection regardless if you disable or change proxies, only restart helps until it happens again.

v8 seems to be really untested, it seems there is much more unknown issues which pop up slowly.

For those who keep using this extension, my advice is to downgrade to previous last version: https://addons.mozilla.org/firefox/downloads/file/3616824/foxyproxy_standard-7.5.1.xpi

But to be secure, prepare yourself for another solution.