Open Bug 117222 (sessionperwindow) Opened 24 years ago Updated 3 years ago

Limit Scope of Session Cookies (new tabs and windows)

Categories

(Core :: Security, enhancement, P5)

Product:
Core
Component:
Security
Type:
enhancement

Tracking

()

People

(Reporter: scott.jones, Unassigned)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

multiple cookie containers patch 13/5
233.07 KB, patch
timeless
: review-
Details | Diff | Splinter Review
multifox error message in private window
33.62 KB, image/png
Details
This is somewhat related to bug 86174 (http://bugzilla.mozilla.org/show_bug.cgi?id=86174). When opening a new window or tab that is blank, I believe that this should start a new scope for the session cookies (those without expiration dates, that disappear when we close the browser). This would allow simultaneous sessions on cookie-based web applications. As a developer of such a web application, this would be extremely useful for me when testing my application. I could log on as one user with certain characteristics and then switch to a different tab with a different user to test the interaction of multiple users at the same time. When opening a window or tab by using the "open in new window" or "open in new tab" options when you right-click a link should keep you in the same session scope. With Internet Explorer, when you start a new IE window by clicking on the program icon on your desktop, it starts with a completely different "session" just like I described above (I'm sorry to bring this up, I'm a loyal Mozilla user, and work on Linux, so IE really isn't an option, and I wouldn't use it even if I did use Windows!).
Target Milestone: --- → Future
Conversely, this could break many sites, where JS is used to launch another window, which then expects to be able to get at cookies set by the session in the first window. I have seen several e-commerce sites use this tactic to take away the user's back/forward buttons, URL bar, etc.
second thoughts, if IE does it...
Just to clarify, IE only does this when you launch a completely new browser by clicking on the "E" logo. All other new windows are connected to the same session. I'm just suggesting that in addition to the behavior that IE has, hitting "Ctl-T" or "Ctl-N" could create a tab or window that has it's own session maybe only if you have your preferences set to start at a home page or with a blank page (not with the last page visited; that could be confusing).
confirming rfe
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
*** Bug 131512 has been marked as a duplicate of this bug. ***
I think that each window should maintain it's own set of session cookies but a new window/tab should just inherit it's cookies (a copy) which could diverge from the first set. Normally, when a link is opened in a new window, the user is following a different paths and the session cookies could interfere with each other. This wouldn't break most shopping baskets since they tend to use persistant cookies. (from bug 131512)
I just ran into this, and I consider this a very important bug. Using 1.0, I find that if I open two Mozilla instances from the Windows 2000 task bar, they both use the same session as demonstrated with <%= session.getId() %> on a JSP page under Tomcat. This is a significant problem for us. We have a web site that has multiple independent "applications" - sets of pages. We want the user to log in separately for each, as different logons have different sets of permissions. We keep the logon credentials in the session. So when I open a second instance of Mozilla, it sees the logon credentials in the session of the first instance and just uses those. The only way I can find to force a new session is to close all running instances of Mozilla. That answer won't be acceptable to our user community. Are there any short term workarounds for this problem?
Scott Jones (comment 3) is correct -- IE does not store different session cookies in different windows, but does do so if you open a second browser process. Mozilla doesn't let you open a second browser process. Any attempts to do so simply result in another window being opened in the already running process. So we can't mimick IE's behavior. The best we could do is to have session cookies belong to specific windows. But as pointed out by Gavin Long (comment 1), this would break many websites and so is unacceptable.
I'm not a Mozilla developer, so I don't know how difficult this would be to do, but it seems to me that new windows that are launched by the end-user (not by specific websites using JavaScript or target=_new or _top directives) with Cntl-N or by clicking on the mozilla icon, in addition to new tabs launched with Cntl-T could (and IMHO should) have seperate cookie-session scopes. This should only be done when the user has set their preferences to open their "home page" or "blank page" NOT "last page visited" (which would definitely ge confusing). If it worked this way, it wouldn't break the websites referred to by gavin (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=117222#c1">comment 1</a>) because the new window would not have been opened directly by the user.
Think about the semantics of what you just proposed. We would now have window groups, where the scope of session cookies were for a specific window group. When a window is opened, it is assigned to a group. After it is opened (by whatever means), the user continues surfing. Maybe he collects a few more session cookies by doing so. But then he wants to do something which requires a new scope of session cookies. He already has several windows open, so he doesn't want to open a new one. Instead he will reuse an existing one. But he'll need to get a window that is not in the window group of his current window. Unfortunately he has no way of knowing which of his open windows are in which group. There is no simple way that you can explain such a window-group model to the user.
I agree with Mr. Morse in #c10 that informing the user which session/window group a particular window is in might not be easy, but let's separate the presentation issues from the functional issues. Can we agree that the user clicking the Mozilla icon in the taskbar or on the desktop should result in a new session, while a new window opened from Javascript or by the user hitting Ctrl-N should maintain the same session? As a web developer, that is the behavior I expect (and need to support multiple "applications" from a single site.) If we concur on that functional model, I have a suggestion to allow the user to identify which window belongs to which session. Add displayable text (that can be toggled on or off by the user, since most probably won't care) that indicates what session/window group a particular window belongs to. Probably should go on the status bar on the bottom somewhere. What text to display? I would opt for a simple number that restarts from 1 each time the Mozilla process starts, e.g., "Group 1". Are there any standards that govern such identification? Perhap make the text part of the document object model and thus modifiable by Javascript to something more human-meaningful.
I think that ^N should create a new window with a new scope. I still tend to believe that anything that's in the current window or opened by Javascript should be in the same scope, things that are opened in a new window/tab should receive a copy of the current scope (but separate) and new windows will start with a new scope. This is based on my own browing habits but when someone opens a link in a new window they are probably going to follow that path separately. This will only break if they're in an online store that holds the entire shopping cart in a single cookie and they continue to add items from both the original window and the clone.
Blocks: 100573
Mr. Rouillier, is there any special reason your "separate applications" have to use the same cookie path. Couldn't they set cookies for someapp.foo.com, anotherapp.foo.com, and so on, or www.foo.com/someapp and www.foo.com/anotherapp ? Or use different cookies for each application?
I think that this is basically a dupe of bug 86174, this one just has a better summary. Anyway, see bug 86174 comment 17 for my proposal for dealing with session cookies.
*** Bug 199908 has been marked as a duplicate of this bug. ***
*** Bug 201505 has been marked as a duplicate of this bug. ***
*** Bug 192659 has been marked as a duplicate of this bug. ***
*** Bug 207390 has been marked as a duplicate of this bug. ***
*** Bug 164969 has been marked as a duplicate of this bug. ***
QA Contact: tever → cookieqa
*** Bug 213075 has been marked as a duplicate of this bug. ***
I believe that IE's way works the best and is untuitive: Any window launched from a browser window (window.open(), file>new>window, ctrl-N, ctrl-T open link in new window...) should share the same session cookie. Any new Browser window launched from the Operating System level icon or menu should have it's own session cookie. That is the way it works in IE and it works for me when I am doing context testing on my workflow system I'm working on. It's also intuitive and will require no user training or preference adjustments. The only drawback is that you cannot use Tabs.
There is a long thread in the forums with steps to reproduce. It's been reproduced accross several platforms. This is an enhancment that would add a great deal of usefulness to Firebird from a developers standpoint. The thread explains why this is a problem for developers and also provides a set of URL's for testing: http://forums.mozillazine.org/viewtopic.php?t=16749
*** Bug 216964 has been marked as a duplicate of this bug. ***
*** Bug 224446 has been marked as a duplicate of this bug. ***
*** Bug 224446 has been marked as a duplicate of this bug. ***
*** Bug 224446 has been marked as a duplicate of this bug. ***
*** Bug 226335 has been marked as a duplicate of this bug. ***
*** Bug 224864 has been marked as a duplicate of this bug. ***
*** Bug 226335 has been marked as a duplicate of this bug. ***
*** Bug 184628 has been marked as a duplicate of this bug. ***
I also vote to handle Ctrl-N and Ctrl-T as a new session scope. Even if the user press one of the shortcuts with setting "use current page" i would like to see a new session. That way, we could redirect the user to the login page. If the user press one of the shortcuts, it might be possible to browse in completley different pathes within the application. But this might break the web-application also, this is one of the problems we have with IE. Not really a problem, but some internal caching strategies cant work on full speed, since they have to reload data unnecessarily.
*** Bug 232578 has been marked as a duplicate of this bug. ***
voting for wontfix. This will be incredibly confusing. What happens if a website uses window.open()? or target="_blank"? It should share the cookies. But then all of a sudden two windows share cookies while some third window doesn't. How do you see the difference? The way it is now is much more clear: every window and tab have the same set of cookies. Try to explain the other proposals in max 10 words. Yeah, this makes some specifix thing to do with some specifix websites impossible, but the other way would make it hard too, and confusing. Besides, it is as good as impossible to do in the backend. darin, dwitte: what do you think?
I am a developer for intranet web applications. If i use window.open() this is almost always a popup window to handle some "search" cases. e.g. Window to search customer, ... or to display some context informations. This popup is without address, toolbar and menu, and therefore navigation is not possible within this popup. But sometimes the user would like to navigate within the same application in two (or more) different pathes. This is currently not possible with mozillas handling of session cookies. The id within the session cookie is used, to store some application data depending on the internal state of the application. I know, with url-rewriting i could workaround this, but this might bring some hidden work to convert the application. And isnt url-rewriting a old technology? I think it is much more state of the art to not use url-parameters to transfer state data between the requests. Sorry if i used more then 10 words ;-)
"allow users to use multiple logins at the same time" <- 10 words. I still don't like it. no matter what, this oculd only be implemented as a pref defaulting to off. Turning it on would be a huge usability loss for users expecting normal behaviour. I don't think any other browser implements this type of feature, even as an option, so no web author would be thinking in terms of being able to use this. And, assuming we don't turn it on by default, this doesn't justify the work it would take to implement it in the current backend. Even Steve Morse thought that most of this was unacceptable. That's gotta set off SOME alarms!
It is not a discussion about multiple logins (we use certificates, so the user do not have to login at all). It should be more a discussion about starting e.g. Gimp xterm or any other application more than once. Almost any application can be started more than once simultaneously, and none of the instances would interfere with another. Why shouldnt this also be the case with web wepplications? And notice, it is only the temporary session cookie what i talk about. IE does this, you can start IE multiple times and the session cookie is not shared. Currently we have to tell our users not to start mozilla twice when using the web applliction, the application has no chance to be informed about the missuse of the session.
mozilla doesn't allow concurrent processes running with the same profile. That's an overall architecture decision beyond the scope of this bug. If that were possible, it would be a different story.
That's an unfortunate decision. It might be the straw that breaks the camels back, so to speak. Web developers and users alike could benefit from this change, but if the back end doesn't support it, and there's no chance that it can be fixed in a new release, then it would make a strong case against switching to Firebird for those users that need to use multiple windows to access the same application using different (session based) logon's. I've been using Fb as my default browser for several months. It is still more useful to me than IE, but this limitation has bitten me more than once.
I don't think that implementing this would cause any trouble for the common user. Please see bug 86174 comment 17 for my proposal for solving this. I'm not sure how easy it is to implement but it definitely doesn't require multiple instances of Mozilla running at once. (In reply to comment #8) > Scott Jones (comment 3) is correct -- IE does not store different session > cookies in different windows, but does do so if you open a second browser > process. > > Mozilla doesn't let you open a second browser process. Any attempts to do so > simply result in another window being opened in the already running process. > So we can't mimick IE's behavior. I dare to disagree. While we can't open a second process, we can make it appear to the user as if we did (as far as cookies are concerned) - thus mimicking IE's behavior. (That's not exactly what I describe in my proposal, though, because I propose creating a new window group for any Ctrl+N/T etc.) (In reply to comment #10) > Think about the semantics of what you just proposed. We would now have window > groups, where the scope of session cookies were for a specific window group. > When a window is opened, it is assigned to a group. After it is opened (by > whatever means), the user continues surfing. Maybe he collects a few more > session cookies by doing so. But then he wants to do something which requires > a new scope of session cookies. How does the user know that he requires a new scope of session cookies? Obviously, the average user knows nothing about that. What they may want is "login to this site again, with another username, without interrupting what I'm currently doing there". He won't be looking for a "separate cookie scope" button. > He already has several windows open, so he doesn't want to open a new one. > Instead he will reuse an existing one. But he'll need to get a window that > is not in the window group of his current window. Unfortunately he has no > way of knowing which of his open windows are in which group. The user won't use the window in which he is already logged into the site where he's going, because that would "interrupt what he's currently doing there" (see above). Instead, he would either open a new window/tab (thus creating a new "window group"), or reuse a window that is not yet displaying the site where he wants to go (therefore not likely a member of the current session's window group - if yes, the user can simply open a new window). Another possibility is staying in the same scope of session cookies only when the user follows a link (whether it opens in the same window or another window/tab or it's opened by JavaScript), and creating a new scope in all other cases, i.e. whenever the user types a new URL, clicks a bookmark etc. That would, however, limit a web developer's capability to test their site. Also, the scope would have to be saved in browsing history. So I stand by my original proposal: create a new scope when the user opens a new window or tab, except when it is opened by following a link. That seems to have only one problem: when the user copies a URL from an existing window and pastes it into the new window with a new scope, they won't get the effect that they may have expected. However, do users ever really do that? I don't think so. Or, another possibility is making this completely explicit: in the File->New menu, where there currently is Navigator Window, Navigator Tab, Message etc., add a new option: "Navigator Window With New Session", and perhaps also "Navigator Tab With New Session". How about that?
Before discussing how the users will see this etc, i want to stress that the backend simply can not support any of the ideas. The amount of work it would be to make it work will simply not justify the gains. Problem one is that the place where cookies are handled doesn't know which window, let alone which tab, the site is loaded that wants to set a cookie. Profile locking is another problem. So my point: it is a huga amount of work to make the backend work and to make it non-confusing, and the gains a re so small that i don't think any of the current mozilla cookie hackers will do the work. And there is a relativly simple work around: start another mozilla with a different profile.
> And there is a relativly simple work around: start another mozilla with a > different profile. This work-around does not seem to work. I've tried several different ways on several different OS's to load more than one profile and it has not worked even once. I have had other developers in my company try to open more than one profile at the same time, again without success. What am I doing wrong? I've tried this with Mozilla, almost every version since this thread has been around. And Firebird since it was Phoenix and around version 0.3 or 0.4. I'm at 0.7 now and still no success. I've tried in Windows 2000, Windows 98 and also Linux OS's, with no success. I work on a large intranet for a small company. We have many levels/groups of employees. For me to do my job, I must be able to open several browsers, while logged in as different people, to our intranet site. As of now, IE is my only choice when I develop. Firebird is my default browser, but when I am trying to make sure that one part of a page does not load for a certain person, but that another part does, I can not do this simultaneously with Mozilla/Firebird.
its possible, I don't remember how to do it on win32, but on *nix if you're not using an xremote startup script, it'll show you the profile manager, and you can start with another profile
on windows you need to set MOZ_NO_REMOTE=1 if you watn that behaviour.
(In reply to comment #43) > on windows you need to set MOZ_NO_REMOTE=1 if you want that behaviour. Ok. I have tried this and it does work but this feature of Mozilla is problematic. I have just turned this off and am now using one profile. 1) First of all, preferences and bookmarks management is greatly obfuscated. 2) Secondly, when I have a window opened with my original (default) profile and I click on a link from my MS lookout (outlook) it opens up the profile selector and does not allow me to choose the original profile. I must open in a new profile. If all the profiles had opened windows, I would have to create another profile to open the link. This is a real pain. Although I am not a fan of IE, I would like to re-iterate that the way that IE handles sessions is simple and intuitive. No changes to preferences would be necessary unless disabling the feature is required. New windows opened from operating system menu icon or script would have a new session. Windows / Tabs opened from an opened Moz window would share the same session. Simple (right?).
> New windows opened from operating system menu icon or script would have a new > session. Windows / Tabs opened from an opened Moz window would share the same > session. Simple (right?). Except that it requirers an enourmous amount of rewrite of all parts of mozilla to support this. So technicly, it is far, far from simple.
(In reply to comment #45) > Except that it requirers an enourmous amount of rewrite of all parts of mozilla > to support this. So technicly, it is far, far from simple. I find it surprising that this wasn't in the base plan for Mozilla. On corporate Intranets multiple web applications often exist all on one server, each using a differing set of credentials. This lack of support for multi- session handling is naive on the part of the developers.
i'm not sure if as an unknowledgable (therefore i can't contribute to mozilla...) watcher of the site if i am suppose to post or not, but, this is really the straw that is breaking this camel's back. I loved firefox/mozilla, love using it... i just can't. Everyone is talking about this bug as if developers will only get bit by it. Normal users, like me, can not open 2 web-based email addresses at the same time. Houses with shared computers (like here also, a roommate with only one computer for a while) leave 2 windows open signed on to the same website (the school's student access site for homework/class forums, etc.) and email, i think 'normal users' may run into this more than you think. It is too frustrating to do anything when every switch requires a re-login while i'm just sitting here. and if a user is browser-savvy enough to choose the tabs over new windows, or any browing feature like that, i think we'd like the choice to open new sessions in a tab or window. Thats the whole reason many of us use the tabs is NOT to open a new window... call me picky, but, it clutters windows systems very quickly. As a user, it is these seemingly small bugs in mozilla that really make it hard to convert over. There is another bug that bites me often, and its been open for 4 years now (47350) and that bothers work sites AND play sites for me. Sorry to rant, but, i do think some things need a little more attention and a little less on things like browser speed etc. at this point, especially if ya'll want this to be adopted by a larger group of 'regular users'
Flags: blocking1.7?
this isn't even remotely close to being anything near fodder for thought for blocking1.7.
Flags: blocking1.7?
*** Bug 245326 has been marked as a duplicate of this bug. ***
(In reply to comment #48) > this isn't even remotely close to being anything near fodder for thought for > blocking1.7. I think it is. It is a major security problem. Imagine two users on the same machine log on to the same web application. Say, for example, they are going to compare something between their logins (it happens often). Hey presto! UserB is now UserA and if UserA loggs off UserB (now A) is also logged off. Even worse, imagine UserA was a power user. I shudder to think of all the security problems caused by this flaw. At the moment, we have to work around this dodgy behaviour with hidden fields and query strings. I know you guys don't get paid but if I were the one who created this bug I would be terribly embarrassed.
> > this isn't even remotely close to being anything near fodder for thought for > > blocking1.7. > > I think it is. Nobody is going to write a complete rewrite of how profiles work in a day. As said, this requires a LOT of work, for little gain. For your problem, you can use different profiles. for this to work, at least the following things needs to be done: make necko aware of windows. somehow make it aware of a virtual tree of windows. (you do want open link in new window to work, right?). think about tabbed browsing. and likely more that i didn't think of. And please stop commenting you want this. We know. The comments only bring this bug closer to wontfix-due-to-spam.
also, if two users are running independent processes, they are not sharing the same profile, so they don't share cookies and/or login info.
Forgive me for "spamming", but I thought this is wht bugzilla existed in the first place - to prioritize and vote on the bugs/features that are most important to the user base. Threatening to not fix a bug because it gets a lot of attention (probably because it's a valid request) seems to be the polar opposite to what the system is intended for. I hope this is not the official stance on bug comments. PS: It's still an important issue and should be resolved. The fact that it wasn't in the initial plan for mozilla is a big oversight.
** spam ** Chris: unfortunately it is far too common for bugs (not necessarily this one) to get overwhelmed with flame-like posts that carry no constructive information. when bugs turn into flame-lists, it becomes increasing difficult to discern the useful comments from the spam. most developers "fear" such bugs because they make life difficult, and when so much spam builds up in a bug, it really slows down the process of fixing the bug. that's not what you want ;-) the hope is that folks will refrain from comment unless it is constructive. BTW, there is a bugzilla feature request for a moderation like capability so that users can choose to only view "relevant" comments. hopefully, it'll get implemented sometime, but i haven't seen much traction on that bug.
*** Bug 248465 has been marked as a duplicate of this bug. ***
*** Bug 249814 has been marked as a duplicate of this bug. ***
Assignee: morse → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
*** Bug 254471 has been marked as a duplicate of this bug. ***
*** Bug 257513 has been marked as a duplicate of this bug. ***
*** Bug 241196 has been marked as a duplicate of this bug. ***
*** Bug 261684 has been marked as a duplicate of this bug. ***
*** Bug 262163 has been marked as a duplicate of this bug. ***
Alias: sessionperwindow
*** Bug 242628 has been marked as a duplicate of this bug. ***
*** Bug 263338 has been marked as a duplicate of this bug. ***
*** Bug 264518 has been marked as a duplicate of this bug. ***
*** Bug 264698 has been marked as a duplicate of this bug. ***
To create a new instance/process of IE, you need to double-click on the icon (not use Ctrl+N). Ctrl+N opens a new window in the current IE instance. If you start a new instance of IE, and try again, I can guarantee you won't have this Yahoo/Rogers problem. Unfortunately, double-clicking on the icon in Mozilla does not open a new instance of the browser, and it seems that many of us on the CC list feel it should. You can see this explanation in comment 8.
Comment #74 From David is correct, an entirely new instance of IE does not share the cookies and there is no collision of logon. That is the behaviour we'll need of Mozilla if its to be considered secure. Please don't make me go to IE, I've probably used it all of 8 minutes in 30 years of being in the IT industry.
Ah, you forgot to give us some vital information: rogers.com is actually rogers.yahoo.com, so you are logging in to the same service. Then it is this bug. But that doesn't take away the fact that this bug is technicly hard to fix. (and don't comment about that sucking. We know, we are looking for ways to fix it, it is just real hard) Also, (to repeat what has been said before) not being able to use two accounts on one website is not a security problem, or a privacy problem. It is just a usability problem. you can work around it by using different profiles. After all this: try to minimize the comments here. If you are not intending to fix it, please don't comment. We know the bug!
*** Bug 266031 has been marked as a duplicate of this bug. ***
*** Bug 269453 has been marked as a duplicate of this bug. ***
*** Bug 270358 has been marked as a duplicate of this bug. ***
*** Bug 271581 has been marked as a duplicate of this bug. ***
*** Bug 272030 has been marked as a duplicate of this bug. ***
*** Bug 272743 has been marked as a duplicate of this bug. ***
*** Bug 273966 has been marked as a duplicate of this bug. ***
*** Bug 275188 has been marked as a duplicate of this bug. ***
*** Bug 278237 has been marked as a duplicate of this bug. ***
*** Bug 277993 has been marked as a duplicate of this bug. ***
*** Bug 278608 has been marked as a duplicate of this bug. ***
*** Bug 279391 has been marked as a duplicate of this bug. ***
*** Bug 272743 has been marked as a duplicate of this bug. ***
*** Bug 280203 has been marked as a duplicate of this bug. ***
*** Bug 280240 has been marked as a duplicate of this bug. ***
(In reply to comment #96) > It seems that even when I completely close the window if other firefox windows were still open after that, then that's exactly the behaviour this bug is about. session cookies are currently only deleted when _all_ firefox windows are closed.
Cristian, Yes, I encounter the problem when there is still a firefox window open, but I also experience the problem when I close ALL firefox windows. Even wait 30 minutes to an hour... It seems that I always get the same session_id, every single time.
*** Bug 130591 has been marked as a duplicate of this bug. ***
*** Bug 282313 has been marked as a duplicate of this bug. ***
*** Bug 283379 has been marked as a duplicate of this bug. ***
*** Bug 287361 has been marked as a duplicate of this bug. ***
*** Bug 288957 has been marked as a duplicate of this bug. ***
*** Bug 289085 has been marked as a duplicate of this bug. ***
*** Bug 288957 has been marked as a duplicate of this bug. ***
*** Bug 290952 has been marked as a duplicate of this bug. ***
*** Bug 295856 has been marked as a duplicate of this bug. ***
no but that's easy to see: keyword=helpwanted, Target Milestone=Future, assigned developer=nobody(Nobody's working on this, feel free to take it)
*** Bug 257513 has been marked as a duplicate of this bug. ***
*** Bug 297763 has been marked as a duplicate of this bug. ***
Actually, building a window tree is also a killer, because windows trees can be joined by named calls to window.open ;-)
*** Bug 306341 has been marked as a duplicate of this bug. ***
*** Bug 306706 has been marked as a duplicate of this bug. ***
*** Bug 307461 has been marked as a duplicate of this bug. ***
*** Bug 309623 has been marked as a duplicate of this bug. ***
*** Bug 296564 has been marked as a duplicate of this bug. ***
*** Bug 310406 has been marked as a duplicate of this bug. ***
*** Bug 310406 has been marked as a duplicate of this bug. ***
Note that HTML5's proposed sessionStorage object has the same requirement as is requested by this bug.
Changing the way FF/Mozilla handles a Parent's child processes (tabs - new windows) would totally hose the browser. All tabs/windows opened from within a parent process should behave as they do now. Allowing the OS to open FF in multiple unique Parent processes which manage their own children is the only way to not break existing functionality, this is how IE does it (and it pains me to say it) and it is the correct way but I understand there are some profile issues that prevents this correct? If unique instances can be had by using multiple FF profiles that the user picks from (like mozilla) then we can deal with that but currently the Profile manager in 1.0.7 just opens a FF browser window not a profile manager.
I've not done any development specifically for FireFox before, but I've been a Linux/C developer for numerous years now... If a developer pointed me in the direction of a few .c files to read which implement the current Cookie and Basic Auth ((which is where my interest in this issue lies)) handling is, I'd be happy to give it a go...
OK, just for tracability, I made the following comments in poor old 115903 and variously elsewhere around Bugzilla and other parts of the outer Hebrides, before finally being chaperoned here to come to rest at Good Old 117222: https://bugzilla.mozilla.org/show_bug.cgi?id=115903#c27 and then c29, c31, c32. (By the way, how do you guys abbreviate those links in these comment windows?) I think that the problem is well enough defined already, I'm just parking my comments at a final resting place, and providing some more back-reading (as if there's not enough already). Good luck with it. Rob
(In reply to comment #139) > (By the way, how do you guys abbreviate those links in these comment windows?) See http://www.bugzilla.org/docs/2.20/html/hintsandtips.html#AEN2386
*** Bug 316188 has been marked as a duplicate of this bug. ***
*** Bug 317457 has been marked as a duplicate of this bug. ***
*** Bug 323182 has been marked as a duplicate of this bug. ***
*** Bug 324552 has been marked as a duplicate of this bug. ***
*** Bug 331823 has been marked as a duplicate of this bug. ***
*** Bug 338278 has been marked as a duplicate of this bug. ***
*** Bug 339184 has been marked as a duplicate of this bug. ***
Target Milestone: Future → ---
*** Bug 343663 has been marked as a duplicate of this bug. ***
I strongly believe that the behavior of IE must be coded in Firefox. (Opening a new Firefox session from OS level must open a new session). This is because sometimes I may wish to login to Yahoo Mail or Gmail with two different IDs and Firefox does not allow me to do so.
*** Bug 345498 has been marked as a duplicate of this bug. ***
*** Bug 345534 has been marked as a duplicate of this bug. ***
*** Bug 345614 has been marked as a duplicate of this bug. ***
*** Bug 347356 has been marked as a duplicate of this bug. ***
If this key bug takes more than 4.5 years to even consider for a fix, it clearly says how bad the design/architechture of the system is.
Here's a stinker. I run a large thinclient deployment at a primary school. The server runs (for PHB-related reasons) Windows Server 2003. The generic student account logs into these computers, giving that account access to the generic student share. Given the architecture of the lab, it's not reasonably possible to do it any differently. So now only one kid at a time can use firefox? Nope, they have to use IE, because IE doesn't care how many instances of itself runs. Mind, I _hate_ IE, but this scoping problem is an utter show-stopper, and appears to be pretty much unique to firefox. If it's an architectural problem with the application, then it's time to get the hip-waders on and fix it. Workarounds appreciated.
(In reply to comment #157) > Here's a stinker. I run a large thinclient deployment at a primary school. > The server runs (for PHB-related reasons) Windows Server 2003. The generic > student account logs into these computers, giving that account access to the > generic student share. Given the architecture of the lab, it's not reasonably > possible to do it any differently. > > So now only one kid at a time can use firefox? Nope, they have to use IE, > because IE doesn't care how many instances of itself runs. Mind, I _hate_ IE, > but this scoping problem is an utter show-stopper, and appears to be pretty > much unique to firefox. If it's an architectural problem with the application, > then it's time to get the hip-waders on and fix it. > > Workarounds appreciated. > Would setting up a bunch of profiles be a work around?
guys, that doesn't have anything to do with this enhancement request.
This bug has been open for a very long time now. Due to the multi-window/multi-tab functionality of the browser it probably not viable to effectively implement session scoping and keep the user informed of these scopes. It must be said that most users do not actually care, know, or want to know about browser sessions, and that it is probably much safer to maintain these sessions between windows and tabs. In scenarios where a new session is required, it is then reasonable to require a launch of a new browser instance/process. This method, along with its implications, will retain most users happy by not changing existing browser functionality, but will also provide those who DO need this functionality (myself included) with an option to do so. It can even be made more difficult to launch a new process, by requiring a "--new" parameter (or similar) - but the ability to do so must eventually be implemented. I think it is safe to set this bug to Depend on Bug 135137, whose resolution will most certainly solve the problem.
If enabling multiple sessions and making the cookie handler window-aware are both prohibitively hard, we should be looking for different methods. Would it be possible to write some kind of code that would make it possible for sites to appear to the cookie handler as different immaginary sites, and make whether they appeared that way a per-tab option? For example, 'www.google.com.a1dqmk.tabcookies.localhost' could be the address the cookie handler would see for 'www.google.com'. In that example, the format would be '<the site's actual address>.<arbitrary tab identifier>.<something that couldn't actually be a domain name>'. No, I don't know what kinds of problems you'd have with 2 different addresses, or with applying that per-tab, but surely they're different at least, and hopefully they wouldn't require such a major rewrite of fundamental code. Sort of speculating here, but it seems like you might be able to do some kind of proxy-server thing and a bit of work with the chromes and/or something like greasemonkey to implement it without ever actually touching the browser backend. (Although admittedly not cleanly or efficiently.)
Being treater as a NEW bug with "enhancement" severity, I don't think this important issue will ever get resolved. Severity and Priority must be set to reflect he importance of this bug, whose resolution is important for long-term success of Firefox. As for the "immaginary sites", neither this nor any other 'quick fix' workaround method is appropriate, and if this calls for back-end redesign... unfortunately, it'll have to be done.
*** Bug 358168 has been marked as a duplicate of this bug. ***
*** Bug 358344 has been marked as a duplicate of this bug. ***
*** Bug 358911 has been marked as a duplicate of this bug. ***
A quick count of duplicates of this bug shows that it has been individually reported 76 times so far. 76 times. Reflect on that for a moment. I know that this will be considered comment spam, but for crying out loud! It's a bug that has every web application developer, web application tester, and just plain power user, pulling their hair out in frustration, and work has not even been started on fixing it almost 5 years after it was first reported. Please fix this already!
bah. instead of trying to count, use https://bugzilla.mozilla.org/duplicates.cgi which shows it's 69. not all dupes are correct or valid, the most recent one is actually at least half wrong if not two thirds wrong. plus there are 7 other live bugs with more duplicates. ignoring that. fixing this bug is nontrivial, it requires working on ipc, and the ipc impl we have is very rough (fairly buggy, and i've read it, i'm sure you haven't). note that in case you do want to work on it, i've assigned it to you. thank you for volunteering. bugzilla is not a place for advocacy, it's a place for patches, let's see yours. in case you haven't read this bug, i'll include a note which i'm sure is repeatedly mentioned: IE takes advantage of the fact that the OS manages its cache and storage and network and various other services. This makes its life much easier. Gecko does not have this luxury, which means it somehow needs to manage sharing/not sharing resources.
Assignee: nobody → magnus.lidbom
I don't believe that assigning this bug to a frustrated user helps.
Assignee: magnus.lidbom → nobody
> ignoring that. fixing this bug is nontrivial, it requires working on ipc, and > the ipc impl we have is very rough (fairly buggy, and i've read it, i'm sure > you haven't). even simpler and lighter applications can manage to share the data between sessions. let me see. almost all of them. and yes, i agree, frustration is the best word the user fells when he starts reading this thread. sorry for this spam. i know i cannot help. > in case you haven't read this bug, i'll include a note which i'm sure is > repeatedly mentioned: IE takes advantage of the fact that the OS manages its > cache and storage and network and various other services. This makes its life > much easier. Gecko does not have this luxury, which means it somehow needs to > manage sharing/not sharing resources. that was supposed to be an excuse :-))
Come on people, FireFox is free, so if its features are not what you want, then that gives you no right to bitch about it. Yes, this feature is a must for any user slightly more adept than the basic surfer, but either you tribute or find another browser. For me FF is just for checking if the layout works, for the real work I have to stick to IE or Opera. That said: I am amazed how complex this is appears to be. I imagine that for each webpage a DOM tree is build. The tree is associated with the tab it is rendered in, and that tab is again associated with its window. So, when the DOM need access to some kind of session cookie storage thing, the engine probably calls a session access function. Assuming both assumptions are correct :-), I cannot quite see why it is such an issue to add some kind of key, derrived from the associated window, to the session functions and by that separate the session storage. This would result in a session-per-window, and given the support for tabs, not a bad approach IMHO.
(In reply to comment #167) > bugzilla is not a place for advocacy, it's a place for > patches, let's see yours. If you say and do things like that, you *WILL* provoke more Flames. CVS is the place for patches. Bugzilla is, IIRC, designed for both discussing bugs and tracking/storing patches and draft patches. (I AM currently allowed to log in and comment, even though I don't have commit access to CVS.) I really hope that you aren't changing mozilla.org policy so that only patch authors are allowed to discuss problems. There is a genuine problem here, even if it isn't gonna be solved in my lifetime. /<Flame>
Thank you all for spamming this bug so much that from now on, I will no longer look at cookies bug and will no longer even think about how to fix them. Thanks all! You sure know how to drive hackers away from your pet bugs.
> You sure know how to drive hackers away from your pet bugs. I believed, that this site was a tool for improving the software like firefox. To make it better, to report bugs and to suggest things that may be useful for someone. But all I got here is this frustration. Now tell me, how do I get to this? 69 voices for this thing and the result? I have reported several bugs and requested several features at bugzilla of wikipedia.org and nobody ever treated me like this there. I have even started to write my own extensions to wikimedia software. Also thanks to their bugzilla. Here? All I am thinking about: It was not worth to try to report somthing. I am a freeware developer of my own. I understand how difficult and demanding the users can be, if they want something. Even rude. But. I do not remember treating them like this. Even if their requests were totaly stupid. I promise, this is the last spam to this bugzilla for a time. I get it. It is not worth for me, 'cos it is not worth for someone who get the know-how to implement.
(In reply to comment #126) > Actually, building a window tree is also a killer, because windows trees can be > joined by named calls to window.open ;-) I don't think that's true any more, thanks to security fixes.
*** Bug 360055 has been marked as a duplicate of this bug. ***
*** Bug 362944 has been marked as a duplicate of this bug. ***
This is bug is rather interesting, i came across of it when checking someone puter , and just got hold of all his sessions he opened thru firefox. I honestly think something ought to be done regarding it. Where does that session identifier value come from ? why shouldn't it be at least brought in random fashion each time you launch the mozilla process ?
(In reply to comment #177) Long reply, your "bug" is already addressed and it's not (at all!) related to this Enhancement Request. First of all, Firefox has ALREADY ADDRESSED YOUR ISSUE: There's a preference under 'privacy', to delete all cookies when "I close Firefox" instead of leaving them on the computer "Until they Expire". But your "bug" isn't the same thing. Usually, SessionID comes from PHP-coded web sites. (They're ALWAYS sent from the web server.) In his case, unless Firefox CRASHED, it's web site programmers' fault that these cookies were left behind. When the secure work is done, there should be a statement session_destroy(); to destroy the Cookie in Firefox, and to erase the 'matching' ID stored in the web host computer. Or maybe he doesn't LOGOFF from these 'secure' sites, that's a MAJOR usage error. When Firefox crashes, it's actually a GOOD thing that your in-progress Sessions aren't lost from your computer and left hanging on the host computer. (At least, I think so.) You can use the FF 2.0 "restore" feature and pick up right where you were. PHP Sessions default to be 'garbage collected' on the host computer after only 1440 seconds, so these can't properly "match up" on the host computer if you haven't actively sent something within the last 24 minutes. Unless the PHP programmer changed the default, which might have been a lazy and dumb thing to (in the cases you're considering). And I don't know whether some badly written PHP Sites would LIKE sessions to persist through multiple Firefox startups and shutdowns, maybe some depend on this 'feature'. There are other non-PHP 'Session IDs', but they behave in similar fashion. Maybe some of them don't expire on the host, or the PHP programmer set a much longer 'garbage collection' timeout? Of course, if you were using HIS computer with HIS profile in less than 24 minutes, it would be reasonable to expect that HIS Cookies still apply. But definitely NOT this bug, and there's already a solution for your 'problem' in the case of shared computers-- just tell Firefox to delete all the cookies when it closes.
(In reply to comment #178) > (In reply to comment #177) > > (...) Unless the PHP > programmer changed the default, which might have been a lazy and dumb thing to > (in the cases you're considering). And I don't know whether some badly written > PHP Sites would LIKE sessions to persist through multiple Firefox startups and > shutdowns, maybe some depend on this 'feature'. > > There are other non-PHP 'Session IDs', but they behave in similar fashion. > Maybe some of them don't expire on the host, or the PHP programmer set a much > longer 'garbage collection' timeout? > > Of course, if you were using HIS computer with HIS profile in less than 24 > minutes, it would be reasonable to expect that HIS Cookies still apply. > But definitely NOT this bug, and there's already a solution for your 'problem' > in the case of shared computers-- just tell Firefox to delete all the cookies > when it closes. > Yes, You're right, but You're forget something. I'm a programmer, and I have some experience between IE and FF session handling. If I testing a website with two or more different user (my job required it), I must close all FF window, or must always choose "empty cache" function when I want to use another session/user state. If I allways click on the login/logout button (on the different users page), I must spend lot's of time, while I create same test surface (or while I make the previous or last used testing case). Sometimes the test cases needed to use two (or more) different session at the same time (for example: chat application). This is the thing what isn't working on FF, but working good on IE. Good: The session was inherited in new window (on IE), which opened by the active window (Ctrl+N), but allways started a new session by clicking on program icon on desktop. Bad: The session was inherited allways (on FF), impossible to use two different session in same time same Operating System. (One chance, to use VMWare :) )
But I think each window with different identities it will work well. Some one open a shopping website,and open a new music website to listen music.But he will go out.He only close the shopping website and go out at once.leave the music web.Now other people use his computer ,and open the shopping website in the firefox history,he can do something the ower of the computer not wish. Test website: http://www.jk333.net/setSession.jsp http://www.jk333.net/getSession.jsp A jsp programmer.
Dear all, I am not certain whether this message trail does related to the defect that I raised. The following is the problem scenario that I encountered:- 1. Login to webmail with username 1 (Tab 1); 2. Login to webmail with username 2 (Tab 2); 3. Go back to webmail / username 1 (Tab 1); 4. Refresh / reload page. The problem is webmail / username 1 (Tab 1) becomes webmail / username 2. I assume the concept of Tab is each Tab acts like a separate windows in IE. Therefore, they should be independent of each other. I don't think it make senses for username 1 suddenly becomes username 2 in Tab 1. Regards, Francis
I second this, and the addition of the Recently Closed Tabs in v2.0 makes this more troubling. The cookies are set to the browser, not the tab, so closing the tab does not kill the session cookies, as it would if it was treated as a separate window (which is the desired behavior I do believe).
We have been using Mozilla Firefox(firefox version 2.0.0.1) as browser for our Web application Project . Recently We came across a unexpected behaviour With Firefox. Scenario: Step1 :I have Retrieved a user details (UserA)from our Database thru our Web applcation in Browser(Firefox). Step2 :In another Firefox Window,i get another user details (UserB). We have both User Details displayed on corresponding screens. Step3 :I modified the data for UserA. Step4 :Immediately i clicked modify for UserB also. Expected to display:Modified UserA details on first screen and Modifed UserB details on second screen. What we got:What happens is that both the screen shows the modified UserB details. No matter whether we work in Tabs or not ,this is the behaviour. Why we suspect this could be a problem of Firefox is 1.The user data's are stored in Session level. 2.We came to know that Firefox uses the same session for any number of its instances unless externally specified(MOZ_NO_REMOTE=1 with new profiles). 3.Lastly it works in IE. Can u tell us that this scenario relates to this bug(bug 117222)?
We have been using Mozilla Firefox(firefox version 2.0.0.1) as browser for our Web application Project . Recently We came across a unexpected behaviour With Firefox. Scenario: Step1 :I have Retrieved a user details (UserA)from our Database thru our Web applcation in Browser(Firefox). Step2 :In another Firefox Window,i get another user details (UserB). We have both User Details displayed on corresponding screens. Step3 :I modified the data for UserA. Step4 :Immediately i clicked modify for UserB also. Expected to display:Modified UserA details on first screen and Modifed UserB details on second screen. What we got:What happens is that both the screen shows the modified UserB details. No matter whether we work in Tabs or not ,this is the behaviour. Why we suspect this could be a problem of Firefox is 1.The user data's are stored in Session level. 2.We came to know that Firefox uses the same session for any number of its instances unless externally specified(MOZ_NO_REMOTE=1 with new profiles). 3.Lastly it works in IE. Can u tell us that this scenario relates to this bug(bug 117222)?
In case of IE if we are opening a browser through Ctrl+N we can block it. But here if are opeing the same from ctrl+N in Mozilla it will go to the home page or url. But from there we canot handle the existing session as its a fresh page. So if possible change the functionality of Ctrl+N as in IE or give option to seperate sessions. That will be good for us developers.
In case of IE if we are opening a browser through Ctrl+N we can block it. But here if are opeing the same from ctrl+N in Mozilla it will go to the home page or url. But from there we canot handle the existing session as its a fresh page. So if possible change the functionality of Ctrl+N as in IE or give option to seperate sessions. That will be good for us developers.
In case of IE if we are opening a browser through Ctrl+N we can block it. But here if are opeing the same from ctrl+N in Mozilla it will go to the home page or url. But from there we canot handle the existing session as its a fresh page. So if possible change the functionality of Ctrl+N as in IE or give option to seperate sessions. That will be good for us developers.
EVERYBODY, PLEASE STOP!!!! There are more then enough advocacy comments in this bug. The amount of spam in this bug makes it nearly impossible to find any useful info, and thus makes it very unlikely that it will ever get fixed. Please, only comment if you know how this bug can be fixed. I mean, if you really, really know how to do it. Which interfaces you need etc, how necko works, how to interact with windows etc. (yes, I know this is a useless comment too, but I hope it stops getting any new comments)
I'm interested in fixing this. Basically, what I want to do is create a nsICookieContainer interface that has all the stuff that's currently in nsICookieService. Add a cookieContainer property to nsIDocShell and nsIHttpChannel(2). Depending on which docshell a new connection is spawned, the cookie will go into a different container. For now nsCookieService will implement nsICookieContainer and continue to dump cookies into cookies.txt. For the future, a separate nsCookieContainer may be implemented that allow custom storage of cookies. nsICookieService will be changed to only have a defaultContainer property, which points to the current nsCookieService container. After this ground work is done, it will allow different cookie containers for different connections/docshells, and thus extensions can set an arbitrary docshell cookieContainer their own custom container. So someone could easily write an extension which captures the session cookies from different windows into different containers. This would also pave way for proper cookie handling in sandboxed HTTP connections. From a brief survey of the source, it doesn't look too hard and I could complete the changes in 2 weeks. Any comments?
I cannot comment on the technical merits of your approach since I'm entirely unfamiliar with the Mozilla code base. However, as soon as you have any code you would like tested I'm your man. I cannot wait for this huge pimple on the face of such a beautiful browser to be removed. Cheers :)
Assignee: nobody → littlecritter
Patch for mozilla to support multiple cookie containers. This patch should be feature complete. Although I initially said it would be split in 2 patches, everything is now in this one patch. There are still some lose ends to tie up (ie debug statements, interface comments). The major change is splitting the nsCookieService class into nsCookieService and nsCookieContainer. nsCookieService will handle parsing, security, privacy etc. nsCookieContainer will hold the list of cookies and read/write cookie.txt. I'll make available a test build soon for people to test the new functionality. Comments on the patch most welcome.
If this works (and I have no idea how to find out), you're a hero. I look forward to this working in the next version!
I've now made a windows build for anyone adventurous enough to test it out. Be sure to read everything in the blog post before making the plunge: http://siphon9.net/loune/2007/05/multiple-cookie-containers-for-firefox/ Also please report any bugs. I'll post some more technical notes about the patch at the end of the week. Hopefully this can make it into Alpha 5.
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → mozilla1.9alpha5
Comment on attachment 264670 [details] [diff] [review] multiple cookie containers patch 13/5 Here are some random thoughts on the patch: First of all, the ginormous amount of changes you need in caller code scares the hell out of me. If you need this many changes, it seems like the cookie service now depends on the frontend to do the right thing. That looks fragile. What's the difference between nsICookieCollector and nsICookieContainer? The interface comments are really sparse about it. You split off a lot of code into a new file. There is an awful lot of logic inside something that should just be a storage container. Why is it split like that? I'd rather split only the part that stores the session cookies in memory, and nothing more. Keep it simple! By the time I got here, the sheer size of the patch made me give up... I didn't got into looking at the details. (btw: I seriously suggest filing a bug for the implementation. This bug is totally unreadable. If you ever need something from this bug in the future, you will have a hard time finding anything useful in this bug, due to the signal-to-noise ratio)
first, its really way too late to make it for alpha 5, since we're clamping down on risk starting tomorrow. second, is there a clear set of design docs that people can review, before spending a lot of cycles on reviewing the implementation? this seems large and scary, especially coming from someone new to the codebase, and its going to need a lot of reviews from various module owners given the amount of changes. third, it seems like there hasn't been much/any communication between the patch author and the module owners/peers. Something this big and scary needs tons of communication and design discussion, not just a giant "here you go" patch. Unless its perfect, which never happens.
as module owner of cookies, i'm happy to see someone working on this, but i'll echo mconnor's comments here - can you draw up something that details why you took the docshell approach, other approaches you considered, drawbacks and advantages, possible bugs/behaviors/fallout etc? i'd like to talk to you in more detail once you've done that. is there a convenient way we can chat (im/irc)?
As a software developer I can appriciate the caution that is observed when a major patch is offered out of the blue. And even though I do not have a direct right of speech, aside from being a professional FF user, after all the "can't be done"s around this issue, I would personally expect a somewhat less hostile position towards someone that offers a "can be done". Maybe the solution is scary and complex, maybe its not correctly documented, maybe there are ways to do it much better, but at least someone came up with a solution! Right?
Tom: I hear you -- I don't think hostility is justified. But I also don't think I saw it here, except perhaps in mvl's use of ! and exhortations, for which he should speak up. It may be a case of style over substance. You are right to say that lack of documentation and scary code can't be barriers to entry on their face, given that existing code is undocumented and scary, all too often. OTOH, we don't want to let that problem grow without bound. But on balance I am on your side in wanting progress, specifically on this bug. To make progress, it would help to have a series of smaller patches. If that's too much work, some more words about design decisions would help. If I can get someone to help without these aids, I will, so stay tuned. But apart from bad feelings, I hope you will stick with this bug and provide either informal docs or smaller patches, or both. And yeah, at least someone came up with a solution. So, thanks from me on behalf of mozilla.org for taking this on. /be
(In reply to comment #207) > except perhaps in mvl's use of ! and exhortations, for which he > should speak up. It may be a case of style over substance. That's partly my style. But having seen the amount of tweaks it took to get the cookie code work right (as defined by a lot of websites out there, not by specs), a huge patch like this really does scare me. Granted, we have unit tests now, but there are no tests for how this works with the frontend (like different windows, different tabs, etc)
My mention of tests was supposed to mean: If we can get tests for this new behavior and a specification of how it works with new windows etc, I would be a lot less scared of the patch. We would also need a spec and tests of how it works when there is no browser window (imagine a xulrunner app or an extension trying to download a file) but somehow, I forgot to type that before submitting the comment.
my two cents: I downloaded Loune's test build and briefly tested it out. The functionality seems to work correctly and I didn't experience any strange behavior. I really like this approach, I think it's an elegant solution. It may be too late for the next alpha release but I hope that this patch is accepted. Kudos to Loune for taking the initiative and patching this far from trivial bug.
I'll write up some more comprehensive design specs on the weekend when I have more time but I'll address some issues raised. (In reply to comment #203) > (From update of attachment 264670 [details] [diff] [review]) > First of all, the ginormous amount of changes you need in caller code scares > the hell out of me. If you need this many changes, it seems like the cookie > service now depends on the frontend to do the right thing. That looks fragile. Unfortunately, due to the fact that there are new channel spawning code all over the place, for every new channel call, code needs to be added to find the document's selected cookie container and applying to that channel. This needs to be done or else cookies from the default container will be used and child elements like images/css/js requests will send from the incorrect container. There's probably a better way which involves making a new childchannelspawner interface, but I opted for the solution which has less architectural change (thus less likely to cause breakage). In other words, where ever there's a SetReferer for the HttpChannel, there will be a SetCookieContainer. > What's the difference between nsICookieCollector and nsICookieContainer? The > interface comments are really sparse about it. A nsICookieCollector holds [a ref to] a nsICookieContainer. Classes that implement nsICookieCollector include nsDocShell and nsHttpChannel, since they are the primary consumers of cookies. nsICookieCollector just consists of a get/setter for nsICookieContainer. nsCookieContainer implements nsICookieContainer which holds the list of cookies. > You split off a lot of code into a new file. There is an awful lot of logic > inside something that should just be a storage container. Why is it split like > that? I'd rather split only the part that stores the session cookies in memory, > and nothing more. Keep it simple! Well, the bulk of it is code managing the hashtable that stores the cookies and the read/write cookie.txt routines. There's also nsICookieManager get/set routines for accessing/looping through the cookies. There are some logging code which will probably need some redeploying. And that's all the container code entails. All the logic was from cookieservice and I did my best not to make unnecessary changes. There was minimal refactoring lest something breaks. (In reply to comment #204) > second, is there a clear set of design docs that people can review, before > spending a lot of cycles on reviewing the implementation? this seems large and > scary, especially coming from someone new to the codebase, and its going to > need a lot of reviews from various module owners given the amount of changes. Designs docs are forth coming on the weekend. > third, it seems like there hasn't been much/any communication between the patch > author and the module owners/peers. Something this big and scary needs tons of > communication and design discussion, not just a giant "here you go" patch. > Unless its perfect, which never happens. Well I did sound off a warning on this bug and also mozilla.dev.platform. It was my mistake that I didn't contact the module owner/peers, but I assumed that posting in this bug and having it assigned to me meant that it was a green light to go ahead. Is there somewhere which lists the correct procedure for this sort of stuff, especially for a newbie like me? (In reply to comment #205) > can you draw up something that details why you > took the docshell approach, other approaches you considered, drawbacks and > advantages, possible bugs/behaviors/fallout etc? i'd like to talk to you in > more detail once you've done that. is there a convenient way we can chat > (im/irc)? I can go on IRC or MSN. If you want to arrange a time (possibly thurs/fri) and place, I'd be happy to comply. The docshell is a natural place for cookie container assignment as it is the highest common denominator in which the user would want to have a separate cookie containment. Already present are analogous properties like allowJavascript, useErrorPages, custom properties which you want to apply to a specific shell making it a good home for the cookiecontainer get/setter. As the container assignment on the docshell is the most obvious, I had not thought of any alternatives. Having said that there could be better places but I don't know them. The obvious bugs are cookies leaking from the default container. Made specifically to address legacy issues, the default container is the container that's created on start up by the cookie service. All new docshells and channels are assigned the default container and will use the default container unless callers specifically change it to another one. This mitigates the risk of having cookies lost because consumers are unaware of the new cookie container code and also upholds the status quo on cookies. The default container has a permanent storage file of cookie.txt in line with all previous versions of Firefox. Since the nsICookieManager interface was moved to the cookie container and there could be many cookie containers (thus many cookie managers), a getService on nsICookieManager will return the default container. Again, this was specifically done to maintain the status quo on existing consumer code such as profile migration. So in summary, transparently, everything should work the same as before. There should be no surprises if you don't use the multiple container functionality due to the safety net provided by the default container. (In reply to comment #207) > To make progress, it would help to have a series of smaller patches. If that's > too much work, some more words about design decisions would help. If I can get > someone to help without these aids, I will, so stay tuned. But apart from bad > feelings, I hope you will stick with this bug and provide either informal docs > or smaller patches, or both. I would gladly answer specific questions on design issues and will definitely take on board suggestions on improving the patch. If it can't make the next alpha, then so be it. Regarding smaller patches, I have some incrementally growing patches made for backup purposes starting from 60k to the size right now. Not sure if those help. Regarding splitting of patches, I could possibly split it for review purposes, but it would be infeasible for committing gradually as it would certainly break functionality. (In reply to comment #208) > That's partly my style. But having seen the amount of tweaks it took to get the > cookie code work right (as defined by a lot of websites out there, not by > specs), a huge patch like this really does scare me. Granted, we have unit > tests now, but there are no tests for how this works with the frontend (like > different windows, different tabs, etc) Just for the record I took no offence and I'm more interested in the professional side of things. Unfortunately it is very hard to track changes when code is split from one file to a new one. But the bulk of the cookie reading/writing/permission code remained the same as before. (In reply to comment #209) > If we can get tests for this new behavior and a specification of how it works > with new windows etc, I would be a lot less scared of the patch. We would also > need a spec and tests of how it works when there is no browser window (imagine > a xulrunner app or an extension trying to download a file) I will produce specs and tests once I have some free time, hopefully this weekend. Regarding the xulrunner app question, as mentioned above, the default container safety net set when the httpchannel is created will catch the cookie. Consumers that expect the previous behaviour will get the previous behaviour. Sorry if this post is a bit rambling. Hopefully I answered all the questions while providing sufficient context. On a side not, I would've loved to have someone guide me during the development of the patch instead of endless trawling through lxr, however, being a newbie, I really don't know how I would go about it. There are so many venues like wiki, groups, irc, bugzilla but none seemed really receptive.
Comment on attachment 264670 [details] [diff] [review] multiple cookie containers patch 13/5 first round of comments were provided to patch author. note that i will try to read the documentation he provides but can not make any guarantees.
Attachment #264670 - Flags: review-
Please fix this issue, I switch to firefox 3 days ago and found my way around, but I just can't live with shared sessions. Back to IE. Sorry guys.
Hi I have tried the compiled patch on windows supplied by Loune I can confirm it works like a dream!!! Simple but perfect in every way. Exactly how it should have been implemented in FF right from the beginning. Nice work, Unfortunately I can't use it all the time at the moment, because of possible rendering issues in the FF3 code, don't want to be making sites work for FF3 before it is released. I really hope this makes it into FF very very soon. Rob
Is this bug concerning opening a new window into a new process? If so, can someone update the title of this bug? Because I had one hell of a time finding it. My motivation for separate processes for each window has nothing to do directly with the issue of session sharing. My issue is the stability of Fx. I'd like to open separate instances, so that if one instance fails, it can be closed (in Windows - end task) without affecting the other instances. Some examples of instability: - unstable plugins - sites out there that cause Firefox to gobble huge amounts of memory, where even closing it and clearing all private data does not free up all the used memory - prankster sites that cause an infinite loop of modal dialogs
This bug is as the title and the rest of the thread describes, it is related directly to session sharing between tabs and windows, of which we believe there should be the option to separate the cookies available to each.
(In reply to comment #0) > This is somewhat related to bug 86174 > (http://bugzilla.mozilla.org/show_bug.cgi?id=86174). > > When opening a new window or tab that is blank, I believe that this should start > a new scope for the session cookies (those without expiration dates, that > disappear when we close the browser). This would allow simultaneous sessions on > cookie-based web applications. As a developer of such a web application, this > would be extremely useful for me when testing my application. I could log on as > one user with certain characteristics and then switch to a different tab with a > different user to test the interaction of multiple users at the same time. > > When opening a window or tab by using the "open in new window" or "open in new > tab" options when you right-click a link should keep you in the same session scope. > > With Internet Explorer, when you start a new IE window by clicking on the > program icon on your desktop, it starts with a completely different "session" > just like I described above (I'm sorry to bring this up, I'm a loyal Mozilla > user, and work on Linux, so IE really isn't an option, and I wouldn't use it > even if I did use Windows!). (In reply to comment #225) > *** Bug 407301 has been marked as a duplicate of this bug. *** > It seems to me that this is straight forward. By definition, a Cookie is visible to all if NO domain is specified, If you specify a domain, it is only visible on that domain. Further restrictions within the domain are by PATH. So if the Session cookie has a domain, it should not be visible to other domains. This addresses the issue of going to a new site/domain on an existing window. Without this feature. Firefox is Restricted to only ONE browser instance to a given SITE. This is NOT a good business case. There are many examples that can be shown where you want to run two instances against the same site with different behavior in each Window. (popups or iframes should maintain the session cookies of their parent window. ) If the development team is against changing the behavior, why not make an OPTION on the Advanced tab for Cookies to say "Separate Session Cookies" or something similar ???
I try firefox 3 beta 5 and this problem exist yet. Somebody know when it will be resolved?
Guys, Wondering if this issue has been resolved in the newer versions, available for download ?
Wow. 7 years and this is still outstanding. And yet all other major browsers don't have this problem...(IE oft-cited; Safari and other WebKit browsers on the Mac give a new session for windows and tabs unless opened by JS). Hard to believe. Also a deal-breaker, since I often have to login multiple sessions to service control consoles, etc. Too bad, I was starting to like Firefox 3.
Loune, are you still around? An updated patch would be welcome (unlike the grand-standing comment 234 and similar -- bugzilla etiquette violations do not help get this or any other bug fixed, however righteous your cause). dwitte, are you able to help get this in now that Firefox 3 is done? It was kept out of 3, which rolled on from August 2007, but we should try to get the fix (or a fix -- the patch can be split up and reworked more easily with Mercurial) in for a future release. /be
(In reply to comment #235) > dwitte, are you able to help get this in now that Firefox 3 is done? absolutely, though the next few months will be hectic for me (graduating). a design review needs to be done (specifically wrt what cookie jars are used in what contexts, and the need for a default jar), and the patch possibly split into smaller bits - a rework of the memory storage model of cookies might be in order too.
(In reply to comment #235) > Loune, are you still around? An updated patch would be welcome Yeah, I'd love to rework the patch. At last glance I think more than half of it will need to be rewritten due to changes in the mozilla code base. There are a few design aspects of the patch that I'd like to consult with the various module owners, but I'm not really sure what the best medium to do this is? bugzilla? email? irc? newsgroups? Also, I don't think I'll be able to finish this this alone in any reasonable time, so if anyone who has worked closer to the source (Dan?) can help as well, it'd be great.
Just downloaded Google Chrome Beta and it works nicely with sessions and tabs.
(In reply to comment #240) > Just downloaded Google Chrome Beta and it works nicely with sessions and tabs. Actually, I take it back: it is showing the same session cookie bug between tabs and windows. I have filed this bug with them too.
Agree with Ed in comment 241. Found the same. Sessions/cookies are shared between tabs, which doesn't make sense since each tab is a process. Oh well, back to FF for the meantime until either FF or Chrome fixes this BUG.
Why not do the obvious and create commands for opening a new session in a new window and in a new tab resp., then put them into the File menu, plus associate them with a keyboard shortcut?
Nektra has written an application, called cookiepie, to go some part of the way in fixing this particular problem. http://www.nektra.com/oss/firefox/extensions/cookiepie/ Using the extension does isolate sessions between tabs and new windows. So as long as the application your using stay's in one window this solution is fine. If the application opens a new window the session is lost in the newly opened window. This solution might help some people.
Nah, this is not the right solution for this issue, we cannot force our clients to install such an extenstion What we expected is that firefox should fix this issue itself cheers
What amazes me is that a plugin can bring a decent solution. It's not 100% the preferred solution, but it sure is 90%. (Left aside if the extra install is acceptable, the solution is good.) I've been monitoring this thread for quite some time now, and I've heard all kinds of arguments about that it's too difficult, that it requires hacks, that offered solutions are not acceptable... This issue is open since 2001. That is 7 years... This is a big issues for developers, and a plugin solves it? As said; amazed. Can we please make the plugin part of Firefox itself?
a decent workflow includes lists, whose items can be opened by right-click, open in new window. for this the plugin is not good. for some cases, great. why not (re)add a parameter for reusing the same browser process or not, as it was the case with mozilla-0.9 (1994 or so) or ncsa browser?
Adding a parameter is also not the right way. the solution should be browser-based feature. Any window opened from the links or by using window.open should reusing the same session as now what it is. But the session should be different for the new fresh window, i.e by clicking the firefox icon to open a new window I'm so curious how come it becomes so unacceptable till now it's not got solved as a so long time since 2001 cheers
F.Y.I. google not interested either. Issue 1086 in chromium: Limit Scope of Session Cookies (new tabs and windows) Updates: Status: WontFix Comment #3 on issue 1086 by jon@chromium.org: Limit Scope of Session Cookies (new tabs and windows) http://code.google.com/p/chromium/issues/detail?id=1086
(In reply to comment #237) Loune: if you're still around and interested in pushing this forward, here's a list of Mozilla module owners http://www.mozilla.org/owners.html , you can find them on irc ( #developers on moznet ) or email them to get in touch with them. Since this patch touches the cookie stuff mostly, I suggest starting discussion with the cookie module owner and/or peers http://www.mozilla.org/owners.html#cookies-and-permissions.
Depends on: 471675
Target Milestone: mozilla1.9alpha5 → ---
Well, this time M$ seems to be ahead of it: http://news.softpedia.com/news/Internet-Explorer-8-New-Session-111037.shtml I'd love to see this (even on a per-Tab basis) in FF too! http://www.firefoxfacts.com/2007/12/15/cookiepie-multiple-cookies-for-the-same-site/ does this too, but I don't really trust this extension and I won't be able to convince my boss of FF when it needs an extension to show the same behaviour as IE. .-(
When will this be released? In Firefox 3.0 nor 3.5 seems to be implemented...
Oh, sorry. I see... "WontFix" I personally believe that this is not a feature request nor a bug... it is an *Analysis failure*. I never spected this from Firefox. (<ironic>)But who cares... here like in Opera, "it's not a bug, it's a feature"(</ironic>). I hope Linux Chrome stable releases soon...
That's the Chrome bug that was set to WONTFIX, as far as I can tell this one never was. That said, this is a really old bug and a serious problem for certain situations (multiple terminals with the same user on LTSP systems for example), and it'd be nice to see it moved forward.
Oops, you are right, Mike Ely. Sorry all (I will not post any more, sorry :\ ). I will forget Chrome and wait in silence.
The lack of cookie isolation among windows is not a feature. It's an ancient Netscape-era design decision. Clearly there are use-cases for sharing cookies among windows/tabs, and also use-cases for isolating (e.g. competitive shopping against oneself -- I do this often enough). Cc'ing Electrolysis folks to get their thoughts. In my opinion we should fix this bug, possibly by using process isolation (but possibly more directly -- dwitte may have fresh thoughts too). /be
This shouldn't have anything to do with e10s: networking and cookies are still going to be managed by the chrome process, so any fix needs to group requests by tab entirely independent of e10s.
(In reply to comment #135) > Note that HTML5's proposed sessionStorage object has the same requirement as is > requested by this bug. IMHO this is the way to fix this bug.
Summary: Limit Scope of Session Cookies (new tabs and windows) → e
Wow, sorry for changing the title. Find-as-you-type bug hit somewhere I didn't notice.
Summary: e → Limit Scope of Session Cookies (new tabs and windows)
I've done some fun things for the Yoono extension: some kind of session per tab by binding one specific cookies database for each selected tab. (We needed it for better multiple account handling of twitter, facebook, ...) I've described our extension feature here : http://blog.techno-barje.fr/post/2009/12/05/Session-per-tab-in-Firefox First, this work says that we can fix this bug/feature with an extension. And with this real world, usable example, we may prove that we don't break the web by adding cookies isolation. That's said, the current source code of yoono is not open source, so I don't know how to mix my will to help Mozilla project and my work ?
Will this ever be done?
Similar in some ways to the recently filed bug 565485 "Scope 3rd party cookies to tabgroup". Maybe there are some synergies there that would let us tackle both problems at the same time.
(In reply to comment #264) > Will this ever be done? I believe it will be done close 10th birthday. Unfortunately, we have no position about this, by a very (real very) long time :( Best regards.
I think this will be partially fixed/worked around by e10s actually, as I think that you will be able to open a Private Browsing window alongside the current window (without it closing). Benjamin, is this correct?
No. e10s may make per-window private browsing easier, but it certainly is not part of our current scope-of-work. Besides which, the networking (and therefore cookie selection) is all done by the chrome process.
OK, I just remember reading that from a Mozilla employee somewhere. Here it is, from Limi: http://www.reddit.com/r/AskReddit/comments/boipt/i_work_on_the_firefox_user_experience_team_and/c0nsdrj The relevant bug is bug 463027 and https://addons.mozilla.org/en-US/firefox/addon/59736/ apparently does this.
I have to say that since first commenting on this bug back in 2004, I've learned to live with the current functionality. Back then we had Firefox/Pheonix and IE 5.5 - not much to choose from. Nowadays we have Chrome and Safari too along with some other fringe browser, all of which are much more standards compliant than the old (and to some degree the new) versions of IE. So in the rare cases where I still need to test multiple users side-by-side, I can at least compare Firefox to one of the other new browsers and be comfortable that I'm seeing nearly identical results. Also, now that I'm used to this behavior I would most likely file a bug if Firefox suddenly STOPPED sharing these sessions between windows and tabs. So unless this separation is done through some explicit action (like a specific menu item or hotkey combination) then I think that after nearly 9 years, this "bug" should probably be laid to rest.
Not to mention the ability to run separate Firefox profiles side by side using the -no-remote switch...
I think it is still important to implement this. Today more than ever, I would like to see it easily possible for a family or couple sharing one computer, to be able to log into multiple Facebook, Gmail, etc. accounts at the same time.
Not to mention the security implications of being able to track a user's movements. Since every window has access to the session cookies of every other window, a malicious website could run a script that periodically checks which cookies (and therefore which websites) are logged on at any given moment, and send back to base a virtual log of the user's movements throughout the web. This seems like an enormous breach of privacy and security. Another potential attack vector is to have a script that continually accesses 192.168.0.1 and addresses of other common routers/modems/network switches and attempts to alter the settings using the commands of common user switches, etc. Since most cheap routers using basic authentication, as soon as a user logs on to check router configuration in one window, the script running in the other window is able to change the router settings. I still can't believe this isn't fixed. It is by far the biggest security hole on the internet. As far as I can tell, the only objection to fixing it is that the best fix is the one used by IE and copying anything for IE is something of a taboo.
My problem is when I open a tab then I login to a certain site, then i close the tab but i dont close the window. If i open a new tab and navigate to the same site, the session is still opened. And the bigger problem, is that when i leave this window opened, but i open another window, the new window is working on the same session as the old window. So i end up having to close the old window where the site was first opened. This is really bothering because i usually have other tabs opened for other sites, and i dont want to close them. This is not helping me to test my work.
jhjjkb
WORKAROUND: Use the Multifox add-on http://br.mozdev.org/multifox/
Thanks, Chris! I filed this ticket almost 10 years ago, and the Multifox plugin does exactly what I wanted to accomplish. As far as I'm concerned, I'm completely satisfied. Cheers. :)
Excellent. Good news after long wait.
Here are some guidelines concerning the lifetime & isolation of a browsing context: http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute
(In reply to voracons from comment #281) > Here are some guidelines concerning the lifetime & isolation of a browsing > context: > > http://dev.w3.org/html5/webstorage/#the-sessionstorage-attribute Taken from the above URL: Introduction: ' Cookies don't really handle this case well. For example, a user could be buying plane tickets in two different windows, using the same site. If the site used cookies to keep track of which ticket the user was buying, then as the user clicked from page to page in both windows, the ticket currently being purchased would "leak" from one window to the other, potentially causing the user to buy two tickets for the same flight without really noticing. ' " When a new top-level browsing context is created by cloning an existing browsing context, the new browsing context must start with the same session storage areas as the original, but the two sets must from that point on be considered separate, not affecting each other in any way. " A new draft spec, part of which is to implement a fix for this bug... It may have been easier to fix this in December 2001?
IE8+ handle this very efficiently: File -> New Session (you can bring back the default hidden File menu bar by right clicking on tab bar) Couldn't have been made simpler than that!
Multifox addon does this. I am using it for the 2 year.
Its easier to use and also easier to manage the cookies. I am able to search cookies by different profile (or session) and clean up only the cookies in one of the profile. Firefox team should just include that addon to their core code.
(In reply to janasx1 from comment #284) > Multifox addon does this. > I am using it for the 2 year. Multifox author claims that starting with Fx version 20 extensions cannot handle private cookies so neither Multifox can. https://github.com/hultmann/multifox/issues/102
this is what multifox displays in private window.
Update to the use cases for this feature request - which have changed since the bug was filed: There is now a multitude of services that alone Google Inc. has dragged into its reign: Search, youtube, blogger, groups, translation, navigation, news. As an answer to this monopolization of internet services a current browser should give his users the tools to separate his online activities from one another. Users should be able to open a window for each of these services with different accounts, identified by respective cookies towards the server. A further feature would allow one to save these sessions and restore them later, in a similar way the "session manager" extension works.
I echo Bernd's comments. The request for this enhancement has accumulated 101 duplicates over the course of 12+ years. In the year 2001 I can quite understand why this might be considered an enhancement request, but if you were to sit down and design a browser in 2014 I'm sure this would be specified as a core feature.
Even if you accept a need to share the session across windows, it seems very problematic to share the session across all Private Windows. If developers are opening windows just to remove navigation etc then FF needs to add an option to restore these. For a start please keep the Private Windows separate from each other, and if necessary block the opening of a new windows from a Private Window (give the user an option to continue if really necessary for some sites).
Depends on: 1157585
Since most proposals seem to focus on tabs/tab groups/windows, I would suggest a slightly different approach: Scope cookies to a tab's origin. E.g. if you visit youtube.com and it tries to load things from the google-origin then the cookies sent to google should be scoped to the youtube.com tab-origin. This would separate concerns such as "I use google search" and "Site Y loads google assets to do its job". If scoped to the exact origin instead of the base domain one could even separate logins to google search and gmail for example. The per-tab-origin model seems to be fairly popular and works well for content privacy extensions such as requestpolicy/µBlock/policeman. Things might be complicated by oauth schemes, but I'm not familiar enough with those since I actively avoid linking accounts from different sites to each other. I guess there are too many different use-cases to implement it all in firefox, so FF should just provide the necessary APIs for addons to isolate individual requests to different authentication/cookie/localstorage realms. I guess bug 1157585 would already provide that.
Depends on: 1165267
Despite the multiple duplicates (incidentally, not all of which quite want session cookies scoped to tabs, although I appreciate the many use cases), cookies work the way they do and this type of scoping would break a lot more than it helps (eg. help, I'm logged in to Bugzilla, but opening a reply in a new tab logs me out). Cookie scoping is a widely-followed standard and just ignoring it doesn't seem very sensible. Comment 281 perhaps shows the way forward. Session storage is already scoped per tab, and if web sites really want to support separate logins, multiple shopping baskets, then they have the means to do it.
(In reply to Ian Nartowicz from comment #299) > Despite the multiple duplicates (incidentally, not all of which quite want > session cookies scoped to tabs, although I appreciate the many use cases), > cookies work the way they do and this type of scoping would break a lot more > than it helps (eg. help, I'm logged in to Bugzilla, but opening a reply in a > new tab logs me out). Cookie scoping is a widely-followed standard and just > ignoring it doesn't seem very sensible. > > Comment 281 perhaps shows the way forward. Session storage is already > scoped per tab, and if web sites really want to support separate logins, > multiple shopping baskets, then they have the means to do it. The approach I was envisioning (which would make intuitive sense) is "When the user has selected to force all site-triggered new windows to open as tabs instead, give each new window (which can, thus, be created only by explicit user action) its own distinct session cookie scope" That way, session cookies are window-scoped and sites don't break because their "new windows" are being opened as tabs within the same window.
Something called the "Contextual Identity Project" is already underway: https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers#Description Bug 1191418 is the meta bug tracking Contextual Identity / Containers, and it seems bug 1165267 is the part of that project related to this one, so I set it as blocking this. Other than that, the only link I found in the project to this bug is: https://wiki.mozilla.org/Security/Contextual_Identity_Project/Private_Session#Related_Work That page states in "Phase 3" of the timeline "Based on user research, design containers around use cases."
I do like the way the web storage standard handles sessions. Especially the idea of allowing contexts to be cloned and considered separate and then subsequently diverging as the cookies change. The up-to-date URL from Comment 281 is now: https://html.spec.whatwg.org/multipage/webstorage.html Looking at Comment 301 referring to: https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers#Description This looks promising. If, for example, "New Private Window" were to open using a freshly created and yet temporary "container" each time it is pressed, that would solve the problem I had raised originally.
Component: Networking: Cookies → Security
Ideally 2 private windows should be isolated totally. Not only cookies!
Specifically: when someone uses the command "open link in new private window" it is sensible for it to be a private window; not that private windows are a collective group. Most people (including experienced IT people with interests in security) would assume that a *new* *private* window had the same privacy features as any other *new* *private* window, not that they would share information. NB lumping private window issues in with a bug that is (arguably) already resolved by the introduction of private windows is not sensible.

I don't really get it. Apparently, it's not a technical limitation, as it's possible with containers (https://support.mozilla.org/en-US/kb/containers).

Containers also work as expected: when opening a new window from an existing window (via JS or by choosing to "open in a new tab"), it remains in the same container, so keeps the same cookies.

The only difference should be to make the container groups more dynamic for private windows. So every time you choose to "open in a new private window", or create a fresh private tab, it should dynamically create a new container for it.

I can understand why splitting cookies on tabs is not possible on the regular mode, as it would break existing sites. But private mode should, first and foremost, be secure.

As a developer, this is also pretty annoying. When I run different versions on my app on a docker server, they are accessible on the same host over different ports. But cookies are shared over different ports and over different tabs (even private ones). The shared cookies (with different secrets) constantly cause logouts on the apps. So I would need to add a DNS rule for every version I install, just to have a different hostname.

The amount of duplicates this ticket received, also clearly shows that people really expect a different behavior.

After reading this thread for 20 minutes I am no wiser. Is there a solution? If no, why? Is it exceedingly difficult? Private windows and normal ones already don't share anything, so can private windows just not share between each other as well? What I want is to open N private windows and have them be completely independent, just like opening N different browsers, so I can log into the same website with different account in each window.

There needs to be an option to separate cookies and browser sessions between windows (with options: always, never, private windows only), so that people who don't want it are not negatively effected and websites that rely on it can still be used.

I don't know if anyone from the Firefox team cares about this (even after 300+ comments and dozends of duplicate issues!), but if I find a browser that supports this I will use it over Fifefox.

Hi,

I wish too this was part of the Firefox Core, but in the meantime I wanted to tell I found a solution to have a separate browsing context for each tab I'm using, and it's configurable. Getting in default Firefox is not that easy and there are tricky parts. If session is per window, what do you do when you move tabs between windows? having separate sessions like that is a great improvement but by using it every day, it breaks quite a few user assumptions (you are logged out when you are in a new tab, following activation links from e-mail sometimes does not work as the browsing context is different than when you signed up, ...)

I'm using temporary containers: https://addons.mozilla.org/fr/firefox/addon/temporary-containers/
With switch-containers: https://addons.mozilla.org/en-US/firefox/addon/switch-container/

the first allows me to create a new container for each tab I'm opening, and it's very configurable so you can choose when to create containers. it allows me to separate browsing contexts easily to the point that I'm always logged out of websites, I often get capachas, ... but that's life now. The switch-container addon allows me to switch from a temporary container to a named container. It allows me to get the logged-in session from a named container so I don't have to log-in each and every time for every website that I am often on.

Hope this can help.

Fission Milestone: --- → ?
a11y-review: requested → ---
Fission Milestone: ? → ---

The bug assignee didn't login in Bugzilla in the last 7 months.
:dveditz, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: lpgcritter+bugz → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(dveditz)

This bug can't be fixed without a large re-design of our cookie system, and it's hard to see someone tackling any time soon given this request is already 20 years old. And some of the security benefits of implementing this (session cookies that are actually ephemeral) would cut against other behavior that lots of people like (opening a tab recently closed by mistake and having it actually still work).

In practice the internal infrastructure we have that does support these use cases is the Containers/originAttributes mechanism, using either Mozilla's own Multi-account Containers add-on for the multi-account use-case brought up early on, or Temporary Containers to make the ephemeral use-case more convenient.

Severity: normal → N/A
Flags: needinfo?(dveditz)
Priority: -- → P5
Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: