Firefox's management of processes and threads

[sheehan]

WOW!

Two year old thread and incredibly the problem you indicate is about IE. Why in the world would a Firefox forum be an appropriate venue?

[Sudhakar_Koundinya]

Hi,

I am just trying to throw a stone in dark to hit the target Anyhow I believe , most of the users uses IE, MS, Firefox and I am expecting the experts will show me the right solutions.

Thanks,
Sudhakar

[arofer]

WOW!

Two year old thread and incredibly the problem you indicate is about IE. Why in the world would a Firefox forum be an appropriate venue?

Could you please enlighten us why the session cookies are SHARED between two different invocations of FF? This is NOT true in IE, and this behavior breaks applications that depend on session cookies.

I have been searching in the fora for some answers, but the question appears to induce avoidance... related issue is:

Can you somehow start a new instance of FF without sharing the session cookies of a single domain?

Session cookies should NOT be shared IMHO: why would one FF "session" see another FF "session"'s cookies except that it may be slightly easier to implement and compatibility with IE is not important.

[the-edmeister]

Could you please enlighten us why the session cookies are SHARED between two different invocations of FF? This is NOT true in IE,

Unlike IE, Firefox runs only one instance of the executable even when attempting a second "invocation"; you are merely opening a 2nd window. Look at the Processes tab in the Task Manager when attempting to open a 2nd instance.

It has not been possible to run multiple Firefox executables since Firefox 0.8 versions, out-of-the-box. You can run multiple, simultaneous Profiles and/or different installations by invoking MOZ_NO_REMOTE to override the built-in lock in the Profile. Whether you are using one installation or multiple versions/installations, each new unique Process will need a separate Firefox Profile; the parent.lock file in the Profile is the limiting factor (which the Environment Variable overrides).
http://developer.mozilla.org/en/docs/Debugging_Mozilla_on_Windows_FAQ

More here if you are interested:
http://the-edmeister.home.comcast.net/advice-html/simultaneous-profiles_versions.html


Ed

[arofer]

Thanks for the explanation and recipes for multi-instance FF.
It worked great to isolate the cookies, including the session cookies.

It seems to me that this is a major design flaw. Here's why: session cookies should NOT be stored persistently: there are good security reasons for this: many cllients do not allow persistent cookies, but they may allow session cookies.
Given that session cookies are not persistent, it makes no sense for lock files to be interrogated between different invoocations of FF, nor does it make sense that you must move your entire profile, including persistent cookies and bookmarks to another location just to isolate the session cookies. While it is conceivable that session cookies are shared between TAB's, it makes no sense to force-fit all invocations of FF into a single "session".

So, it appears that the Mozilla developers have made some rather arbitrary decisions here that decrease the usability of the browser. Web application developers using session cookies, for example, will need to provide warnings about this behavior to their customers, who will be less disposed to use FF than otherwise.

It might be a good idea for the FF documentation to be updated to explain the idiosyncrasies of the session cookie implementation in FF, and the lack of support "out of the box" for multiple simultaneous sessions. I had to spend quite a bit of time researching this issue.