Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Description • 16 years ago

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 (.NET CLR 3.5.30729)

Today we noticed (at least on two different computers) that the automatic update to Firefox 3 modifies the proxy settings of the current profile. This issue only happens with the major update. If you start a parallel installation of Firefox 3 without doing the update the proxy settings are correct.

Steps to reproduce:
1. Install Firefox 2.0.0.16
2. Create a fresh profile
3. Set prefs for manual proxy (we have one for HTTP/HTTPS)
4. Check for updates and upgrade to Firefox 3.0.1
5. Open the network panel and see that "Auto-detect proxy settings..." is enabled.

Users who has to be use a special proxy server will fail in such a case to connect to the internet. The proxy settings should definitely not be modified by an update.

If you do the same steps 1-3 and start afterwards an parallel installed Firefox 3 you will see that the manual proxy settings are still selected.

It looks like that we modify the proxy settings during the automatic update. 

Something we can block? The major update is still delivered to our users. So what could we fix for users who haven't updated yet?

	Robert Strong (they/them - no direct email)
	Comment 1 • 16 years ago

Henrik, are these values stored in the profile? If so, it isn't application update that is modifying them and this would be a bug in another component.

	Robert Strong (they/them - no direct email)
	Comment 2 • 16 years ago

App update doesn't modify preferences except in that the app itself can provide new default prefs. This bug isn't going to get any traction under app update so moving to Firefox -> General so it can be triaged and assigned to the proper component.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 3 • 16 years ago

Sorry for the late reply Robert. But hadn't time earlier. I made some more testings on that and noticed that I was a bit too quick in blaming the major update.

But anyway, with a new profile (and another visible window size) I found out why that happens. Normally I ran several tests with an additional profile to be able to use Bugzilla beneath these tests. Same I did while running the major update. I specified the MOZ_NO_REMOTE environment variable to start Firefox 2.0.0.16 in parallel to Firefox 3.0.1. Now I started the update check and applied the major update which results in updating the correct application. After the update is applied Firefox get restarted automatically - without the question which profile should be used. Due to this behavior I wasn't able to see that the updater doesn't start the updated version but used the already running Firefox 3.0.1 process. That shouldn't happen because the environment variable is still set. It should be obeyed by the updater when starting Firefox.

This is not major anymore because it will only happen in rare cases even with multiple profiles in usage. Any chance to get this fixed? Personally it will help me a lot while triaging or verifying bugs.

I'll put it into the profile and startup component because I'm sure that also affects Thunderbird.

	Robert Strong (they/them - no direct email)
	Comment 4 • 16 years ago

The updater no longer needs to be elevated by the app (it handles it itself) for 3.0.2 and above since. Also, the code that de-elevated on restart which caused the loss of the env vars is no longer used for 3.0.2 and above. Can you try to reproduce using a trunk nightly?

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 5 • 16 years ago

Robert, do you have the bug number which fixed this part for Fx3?

I tried the update process by running the following browsers. None of them showed this behavior. So it only happens for 1.8 branch. So it will be fixed by the bug I don't know atm.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 6 • 16 years ago

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.3pre) Gecko/2008090206 GranParadiso/3.0.3pre (.NET CLR 3.5.30729) ID:2008090206

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080902033133 Minefield/3.1b1pre (.NET CLR 3.5.30729) ID:20080902033133

	Robert Strong (they/them - no direct email)
	Comment 7 • 16 years ago

(In reply to comment #5)
> Robert, do you have the bug number which fixed this part for Fx3?
> 
> I tried the update process by running the following browsers. None of them
> showed this behavior. So it only happens for 1.8 branch. So it will be fixed by
> the bug I don't know atm.
Bug 437349. I'm not planning on backporting this to the 1.8 branch.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 8 • 16 years ago

Thanks Robert. I'm fine with it. Everyone should upgrade to Firefox 3. So we can resolve this bug as WONTFIX.

	Henrik Skupin [:whimboo][⌚️UTC+2] Reporter
	Comment 9 • 16 years ago

At least this was fixed on trunk by bug 437349. For better tracking lets move it over to FIXED.