345455 - Roaming User doesn't support proxy, crashes

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: Roaming, enhancement)

Description

[r.s.t]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2

On startup Seamonkey tries to load the remote profile and asks for the login data for the remote profile store.
If there is no direct connection, i.e. you need a proxy to pass the firewall, Seamonkey crashes, after you do anything (e.g. press cancel).
The configured proxy settings in the preferences are not used!

Reproducible: Always

Steps to Reproduce:
1. Configure roaming user with HTTP/FTP.
2. Restart Seamonkey
3. Try to login to your remote profile store or press cancel


Actual Results:  
Seamonkey crashes.



I suppose it happens only, when you have to use a proxy to pass the firewall.
It seems that it doesn't depend on the type of authorization mechanism used by the proxy. (I tried it with NTLM and no authorization.)

The only way to recover is to restore a backup version of registry.dat or to try to patch the registry.dat with these perl-tools:
http://www.alain.knaff.lu/howto/MozillaCustomization/find.html

Comment 1

[timeless]

when you say crash, do you mean that talkback or the windows error report dialog appears? if talkback does, please find the incident id.

if not, please confirm that it doesn't.

note that your edge case is a real pain. an implementation detail of our product is that proxy configuration is stored in the *profile* which you roamed and therefore don't have until later, thus this is a catch22.

since you're a potential user, can you imagine multiple roamed profiles each needing *different* proxy settings to retrieve their settings?

Comment 2

[r.s.t]

Sorry, there is a mistake in my description:

Seamonkey crashes only when you press cancel.
Then the windows error report dialog appears.

But the problem is not the crash! It makes no real difference for me, if SeaMonkey crashes or terminates regularly, because I am forced to press cancel.

The problem is, that you are asked for the password for your remote profile store, but the login data is not send to the profile store. It is send to the authorization service of the proxy server. Of course this expects totally different login data.

Comment 3

[Frank Wein [:mcsmurf]]

So the proxy is a transparent one?

Comment 4

[r.s.t]

Yes. Our company uses the Microsoft ISA Server.
All HTTP requests are redirected to this proxy, if you didn't configure the proxy (resp. if you ignore the configured proxy).
After redirection the proxy requests the NTLM-based authentication.
And this login request I get "inside" your login request for the remote profile
store. 

I suppose this problem will be not very uncommon for users, who are interested in roaming profiles, because they want to synchronize their home profile with the one in the company. And bigger companies or organizations tend to have such proxies.
I have no such problems with the browser, mail or calendar (including remote calendars).

Comment 5

[timeless]

you didn't really answer my main question:
> since you're a potential user, can you imagine multiple roamed profiles each
> needing *different* proxy settings to retrieve their settings?

but thank you for clarifying the other bits.

for reference, generally you don't need to cc yourself to bugs you file, bugzilla will generally spam you for life anyway.

Comment 6

[r.s.t]

I am not sure what you mean with "multiple" roamed profiles.
I would like to synchronize parts of my profile on my account on different machines (e.g. home, company, girl friend, university, parents, pda,...).
On all machines I need different proxy settings, because there are very different ways to connect to the internet.

If you think of a user roaming inside of a local network you wouldn't usually need different proxy settings, but in this case you could use the file copy mode and don't need your proxy settings at all.
When a company has roaming users, they usually provide a solution where you can put your entire profile in a personal network location (home directory) and with this you don't need the roaming profile mechanism at all.

In brief: the proxy settings should always be local and not part of the remote profile.

Comment 7

[r.s.t]

The severity level "enhancement" doesn't really reflect the real severity of the problem.
If a user, who has a transparent proxy (with authentication), tries the Roaming User feature once, his profile is not accessible anymore and SeaMonkey doesn't start anymore. And there is no easy way to recover the profile.

This is worse than a simple crash!

Comment 8

[timeless]

this is an enhancement because there is no code to do what you want, code will have to be written, at some point you can either:
1. write it yourself
2. pay someone to write it
3. wait for someone to write it

(or some combination.)

I exist, I have a laptop, I take it home, I take it to work. At work I have a proxy, at home I could have a proxy (thankfully, I don't).

Suppose I configured my browser to have 3 profiles. Work, Home, Gecko. Would you expect me to want to be able to use my Work profile from both work and home using different proxy settings? Supposing you don't. would you expect me to want the Home profile to be able to roam using a different proxy server than the work profile?

Put another way, How many profiles should I create on my laptop in order to use these 3 profiles at 2 locations. And how often should I have to enter proxy configurations and roaming server configurations.

These questions are designed to evaluate how much work is required for someone to implement this feature.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to comment #2)
> But the problem is not the crash! It makes no real difference for me

matters to me, the crash makes it a bug, not an enhancement. Maybe not quite the bug you want though.

(In reply to comment #1)
> note that your edge case is a real pain. an implementation detail of our
> product is that proxy configuration is stored in the *profile* which you
> roamed and therefore don't have until later, thus this is a catch22.

It's not a catch-22, it was part of the design of the Netscape 4 roaming feature and could have been here. If you have a desktop at home and a desktop at work, most settings "roam" but some, like proxy, stay machine specific. If you carry around a laptop and need to access from different spot you use different local profiles, just like you have different wireless profiles so you don't have to enter different WEP or WPA keys all the time.

(In reply to comment #8)
> Put another way, How many profiles should I create on my laptop in order to
> use these 3 profiles at 2 locations. And how often should I have to enter
> proxy configurations and roaming server configurations.

Now *that* is an edge case. What this bug is describing sounds fairly normal and sane.

Comment 10

[Daniel Veditz [:dveditz]]

It should at least not crash.

Comment 11

[Frank Wein [:mcsmurf]]

Reporter: Could you possibly try a nightly build from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ to get us a Talkback ID for this crash (I would download the .zip build, simply extract it somewhere and run it)? When you crash with a build from that location, Talkback should appear and ask you to send a crash report. Click on Send and after that launch talkback.exe from the components/ subfolder to get the Talkback ID of your sent crash report.

Comment 12

[r.s.t]

(In reply to comment #8)
Actually there are different issues here.

1.
The feature "Roaming User" doesn't work as expected:
I can select different items to be part of my roaming profile.
The proxy settings are not in this choice, and I wouldn't expect it to be.
So it should be in the local part of my profile.
These proxy settings should be considered when connecting to the remote part of my profile, the same way as they are considered in every other http request in SeaMonkey. (So I don't believe, that there is really "new" code to be written.)
So for me this is a normal bug.

If you want to incorporate the proxy settings in the choice of items, which can be roamed, then this would be an enhancement.

2. 
The problem, that after enabling the Roaming User feature your profile is not accessible anymore, makes this bug critical.

3.
It is a bug, that you get the login request of the proxy server in the dialog of the login for the remote store.

4. 
It is a bug, that SeaMonkey crashes after pressing cancel.
But this crash is not that critical.
The question is, what SeaMonkey should do, after you press cancel. Open the Profile Manager or just terminate?

5. 
If you want a roaming machine (laptop), which needs different access data in different areas, you need a new concept for this, which has to be independent of the profile.
This is an enhancement.


(In reply to comment #11)
I will do this soon.

Comment 13

[r.s.t]

(In reply to comment #11)
> Reporter: Could you possibly try a nightly build from
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ to get
> us a Talkback ID for this crash (I would download the .zip build, simply
> extract it somewhere and run it)? When you crash with a build from that
> location, Talkback should appear and ask you to send a crash report. Click on
> Send and after that launch talkback.exe from the components/ subfolder to get
> the Talkback ID of your sent crash report.

I tried the last nightly build, but the crash wasn't as reproducible as in the stable build. The crash occurred only ones (while exiting SeaMonkey, not at startup), the 3 steps of the Talkback Agent appeares, but after this, there was no incident in the list of the agent. I suppose the problem was, that the proxy settings in the Talkback Agent weren't set.
Does the Talkback Agent support NTLM-proxies?


But what about the real problem?
Do you admit, that "Roaming Profile" doesn't work as it should, at least for users with a transparent proxy, which requires authentication?

When there is version to test, please mail me and I will do it.

Comment 14

[timeless]

http://www.pradeepkumar.net/2006/06/28/MozillaTalkbackProxyAuthenticationIssueP2Solution.aspx describes how to get talkback to send a report to us if your proxy is more complicated than a basic one. sorry.

Comment 15

[r.s.t]

Roaming User still doesn't work in SeaMonkey 1.1 !!

This feature ignores the proxy configuration.
If you depend on a transparent proxy, SeaMonkey asks for a password. After entering the password SeaMonkey freezes.
Your complete profile is inaccessible after the configuration of a roaming user.

This dangerous bug is not listed in the "Known Issues"!

It is very common to depend on a transparent proxy at work. And the typical need for a Roaming User is to share a common profile at work and at home.

The solution would be very easy: Just respect the proxy settings in the local profile, when you try to access the remote profile.

Comment 16

[Ben Bucksch (:BenB)]

rst,
It seems we're confusing several things here:
- explicit proxies in profile vs. transparent proxies
- proxies requiring authentication (via HTTP digest?) and free proxies

It seems to me your last comment applies to proxies with authentication. The vast majority of proxies (explicit and *esp* transparent ones) require no authentication at all, but trust the internal network and just route outside.

Also note that the roaming server is mainly supposed to be on the local network. Roaming is made to roam between machines in a single network, not to roam between work and home etc..

> very easy: Just respect the proxy settings in the local profile

There is no local profile. Roaming happens before profile initialization, and overwrites the local profile.

Comment 17

[Ben Bucksch (:BenB)]

So, basically, sroaming doesn't support proxies, and if it does, it needs hardcoded support, we can't use prefs.js, we don't even have a preference service yet. I don't even know if that's possible in Necko, to set a proxy without going via prefs.

Comment 18

[timeless]

it is possible to init the prefs service repeatedly, we could store a local prefs file with very little, including a proxy setting or 50 and when we download the real prefs file, we could store it with a different name and tell prefs to load and write to it instead. when we quit, if necessary, we could reinit prefs with the stub file if we need to change the roaming settings.

Comment 19

[Ben Bucksch (:BenB)]

> it is possible to init the prefs service repeatedly

No, tried that, doesn't work. Once initialized, it won't reinitialize properly again, unless the profile shuts down. At least that's what I saw back then, and I tried for *several days*.

Comment 20

[r.s.t]

(In reply to comment #16)

It is a transparent proxy with authentication (even worse: with NTLM).
There is a solution for the authentication problem: I use an explicit proxy proxy which handles the NTLM authentication. (Fortunately I usually don't need this for SeaMonkey)

So the problem would be solved for me, if either roaming supports the authentication of transparent proxies or it supports explicit proxies.

I supposed that Roaming User feature stores the selected items in a remote profile and the unselected ones in a local profile.
If not, where do you put the unselected ones?

Is there any reason, why roaming is not intended to roam between different locations (resp. networks)?

(In reply to comment #18)
Wouldn't it be better anyway to have a local copy of the complete profile in case the remote profile is unreachable?

(In reply to comment #19)
If it isn't possible to reinitialize the prefs service properly, wouldn't it be possible to shut down the service after reading the local part, and start it from the scratch after getting the remote profile (transparently for the user)?

Ralf

Comment 21

[Ben Bucksch (:BenB)]

> Is there any reason, why roaming is not intended to roam between different
> locations (resp. networks)?

No, nothing apart from speed and privacy.

> Wouldn't it be better anyway to have a local copy of the complete profile in
> case the remote profile is unreachable?

We do.

> If it isn't possible to reinitialize the prefs service properly
> wouldn't it be possible to shut down the service after reading
> the local part, and start it from the scratch after getting the remote

That *is* reinit. And it didn't work. No, I cannot init and shutdown and reinit the whole profile, because I am hooking up exactly at profile init.

Comment 22

[Daniel Veditz [:dveditz]]

(In reply to comment #18)
> we could store a local prefs file with very little, including a proxy setting

The Netscape Communicator roaming feature did something like this, there were "local" prefs that did not roam and described the things needed -to- roam such as proxy settings. I think there was a different function in all.js to flag these, local_pref() vs pref() or something, so the pref service knew which ones to save locally and not roam.

Comment 23

[Ben Bucksch (:BenB)]

So, hack prefs service? Sure, that would be a way. Would require approval by whoever owns that.
In fact, it may be an option for the replacement of nsIRegistry (which is gone in Firefox), instead of ini files, for the basic roaming prefs like server etc. as well - I would need to think about it, if that's possible, too.

Comment 24

[Benjamin Smedberg]

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.