From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1) Gecko/20010607 BuildID: 2001060703 Session-cookies eg session-id for a php-page. Persists until you have closed the app completely. If I go to a page, get a session-cookie, open tasks/mail. Close the browser window. Open a new browser window. The session-cookie is still there. When I close all Mozilla-windows. It is gone. Reproducible: Always Steps to Reproduce: 1. open mozilla -mail 2. open mozilla 3. Goto a site with session-cookies in browser 4. Close browser window(s) (all of them) 5. Open new browser window 6. The session-cookie persists Actual Results: The session-cookie persists. Expected Results: The session-cookie should have ben removed.

I don't know if this bug is valid. But I can confirm this. -> cookies

As long as you haven't closed out the app, you are still in the same session.

Sure. It works like that. But SHOULD it work like that? I often have mail-window open. It has a much different role than the browser. Think that a session-cookie should be deleted at least when there are no more browser-windows open. What do you think?

I definitely think the "session" should be the application session, not the browser-window session. Closing all the open application windows is not a "special" event. Think of it this way: Why should the session cookies be "forgotten" when closing a single window (leaving no open windows), but not when closing 8 out of 9 open windows (leaving 1 open window)? I suggest marking this bug invalid.

I do not think this should be closed. As I see it Mozilla contains several applications in one program. You got the Browser, Mail, Composer and IRC-client. Sure Mail and Composer share html-rendering with he browser but there is where it ends. Think of this: From any (almost) browser window you can get back to the page with the cookie. If you only have a mail, irc or composer - window open you cannot go back to your old webpage. You would need to open a browser window to do that. Thus you (at least I) would expect the session-cookie to be forgotten. Think the session-cookies should be isolated in the following order: 1. Application (Multiple users, using X on the same server eg) 2. Webbrowser-domain of Mozilla Best regards Per-Olof Pettersson

I'm not convinced. Let's say I'm working in a browser window and then switch to mail to read and send some messages. I then go back to Web browsing. Why should it matter whether I left my browsing window open, or closed the window and opened a new window? I can see what you mean, but I think the majority of users (including me) expect "session" to refer to the application session (between starting and quitting Mozilla). I still favor marking this bug invalid.

I think this should be kept open and addressed. Cookies relate to the browser window, not the application. You dont have cookies in news or in chat or in composer do you? If I did a browser-only install should the session end on exit from Mozilla or on exit from the last active window? i would say they are both the same... If I open a webpage that uses a session cookie and then close my browser down, the cookie should be expired. This is how IE, NS4, Opera etc etc etc does it.

> This is how IE, NS4, Opera etc etc etc does it. Not true. Mozilla and NS4 do it exactly the same.

Uummm you are indeed correct. I made an assumption based on a project I was recently working on. Thinking back the version of Netscape in use was Navigator 4.08 so it was only a browser. That project involved a cookie holding session specific information that was meant to expire once the BROWSER was closed. It worked perfectly in IE, Opera, NS4.08 but did not work in Mozilla unles you killed the entire application - which is a bit of a bitch as it negates the benefit of having QuickLaunch.

Quicklaunch is another issue and the session cookies for it are being addressed somewhere else. If all windows are closed, indeed the session is ended.

I confirme, under Windows with quicklaunch enable, this bug is very annoying (with v0.9.8)

Just to clarify my comment #10 above. When all windows are closed, all session cookies are released. That is true whether or not quicklaunch is enabled. The bug that deals with releasing session cookies when quicklaunch is enbabled is bug 129819 and the patch for it has been checked in.

OK. QuickLaunch issue is resolved. Still a bitch though. I worke remotely and use chatZilla. To fully expire a cookie I need to close it which is damn annoying. I am working on various e-commerce systems and session expiration on BROWSER shutdown is crucial. Apart from anything else, just testing functionality that is meant to occur on browser shutdown is a pain as I have to either kill all windows, or disable then re-enabl cookies in prefs or do as I am now and use Moz for chatZilla and NS7 for browsing. How difficult would it be to do this?

If I receive a session cookie while browsing, and then I shut down that window or tab, I would expect that "session" to have ended. You have to look at it from the perspective of websites and how they would track visits and not from the application's perspective.

Security-wise, many websites tell users to close the browser window to ensure they are logged off (and that their session is expired). This can cause unexpected security issues: imagine on a machine in a public library, someone goes to a secure website, logs in, downloads a file, then closes the browser window. If any other browser windows (or even the "download manager") are left open, anyone can walk up to the system, go to the site, and be logged in as the previous user, providing the session hasn't timed out on its own. It is also non-intuitive--why should the user have to close their browser window viewing google.com just to expire the session in their other browser window viewing amazon.com? Even though all the browser windows share the same process, they should still _appear_ to be several independent instances of the same application.

I also think, there should be a possibility to start a new session. I am a web developer and I often need several sessions open concurrently for testing reasons. Up to now I used IE, where there was such a possibility. If you open new window from existing window (right click on hyperlink, Ctrl-N, file->new window menu, etc.) they share the session. If you open a new instance by clicking on IE shortcut icon, the new session is started. I don't insist on havin exactly the same behaviour as in IE, but I definetely would like to have multi-session functionality. Favourably even without necessity to close all the browser window. Perhaps the rule could be: tabs share sessions (session cookies), windows don't. It shouldn't be that difficult to implement.

Scenario: I browse an online catalogue of products. I right click a product and open its details in a new window. Then I finish browsing the catalog and close that window. The session has _not_ ended, because I still have the other window. And when I go to a completely different website in that other window, the session _still_ hasn't ended, because I might use the Back button to go back. However, when I close the window, the session _has_ ended, even if I have other browser windows open. If a site is making the user close a window to finish the session, that's just false sense of security - it doesn't work that way even in IE, as described in comment 16. Solution: 1) Session cookies should have a session-ID, so that there can be multiple cookies with the same name, domain and path but different session-ID. 2) Windows/tabs should have a session-ID property. 3) Session-ID's should use reference counting. 4) New browser windows/tabs (Ctrl+N, Ctrl+T, Ctrl+1, new start of Mozilla...) should get a new, unique session-ID. They would use this session-ID (with refcount=1) to identify session cookies that are relevant to them. 5) When one opens a link into a new window/tab, or when a new window gets opened by JavaScript, that new window/tab should inherit the session-ID from the parent window/tab, AND increase the reference count of the session-ID. 6) When a window/tab is closed, it should decrease the reference count of its session-ID. If it is zero, the session can be freed, and all its session cookies deleted. How 'bout that? (And setting hardware/OS to all/all.)

profile sharing will probably provide the basic backend functionality for this, though there'll be much more to do in terms of allowing multiple processes of mozilla before it'll actually work.

Woah, hold your horses there! Multiple processes is overkill. I don't think it's necessary to have that in order to implement comment 17. In fact, I'm inclined to think that it's realizable completely in JS, without touching a line of C++, though I'm not sure about this.

For my 2 pennies worth, I'd like to see this fixed. I'm using Firebird with multiple tabs, and do lots of web development. When I connect to a local application server it gives me a JSESSIONID, but when I close the tab it doesn't get deleted, even though I have other tabs totally unrelated to the page the session was for. It's not just other tabs being open either, viewing the source of a completely different page on a different site, or using the bookmark manager means the cookie won't get deleted, and that just seems plain wrong. I'd like the tabs to be treated as separate mozilla/firebird instances (or sessions), and if you close the tab, kill any session scoped cookies associated with that tab.

Forgive me if this is off-topic / incorrect, but isn't this also a possible security issue? If different tabs/windows aren't sectioned off from one another, this isn't there the potential for the session cookie information set by a sensitive site in one tab (say online banking for instance), assuming that it uses session cookies, to be read by sites in other tabs/windows?

no. cookies can only be read/altered by the sites that set them.

So the only possible security related issue here would be the case where you close out a site without actually logging out (but don't exit Mozilla), leave your desk, and some co-worker or other family member comes in, opens up the site again, and some of the checks are bypassed because the session cookie is still active - as per comment 15. I just confirmed this both with phpBB boards (MozillaZine), which is not that big a deal, and my own online banking site, which is much more of a big deal. I would have to agree that if I close my online banking tab I should be forced to login again if I revisit it (without first exiting Mozilla). The fact that I don't explicitly log out is incorrect user action, but any negative results from that shouldn't be impacting the browser side of the equation. As already suggested, if said online banking site opens up a 2nd window/tab of its own, existing session cookies should be duplicated but for the unique id associated with that new window/tab, so that security credentials are maintained. However, this does pose problems in terms of what new windows/tabs some sites will open up. You could say that only if the originating domain is the same should the session cookies be copied, so as to avoid popup/redirect sites, etc. - but what of sites that use a merchant service where the a totally different, yet legitimate, domain is used? Is there any way of determining legitimate vs. illegitmate use here? In any case, I would first implement things so that only new tabs/windows created by the 1st site can make use of that 1st site's information. Then (try to) deal with this further aspect of things in a separate bug. Should the "privacy" keyword be added here?

Forget the part of my last comment about addressing the situation where one site opens up a totally different site (legitimately or not) being a problem. As I *had* known before I stupidly asked, and as Dan already replied, "cookies can only be read/altered by the sites that set them". I seem to be having some kind of intellectually challenged day today...

Most ecommerce/banking sites also use timeouts in case the user does not log out or their connections drops and they can't get back online etc.

Bug 117222 might be a dup.

I can confirm that Firebird 0.6 does not expire session cookies when all instances of the browser are closed. I guess it is due to the quickstart feature as firebird is still active as a process under NT4. This is very bad though, as a user should not be expected to know that once they have closed down all visible signs of the browser that it will still be hanging onto their session variables (typically used to confirm security credentials). I have closed down Firebird and then come back to the machine the next day, launched Firebird and been horrified to find I was still logged into a PHP application. (NB: It is on a testserver which has no timeouts set). But Firebird should NOT rely on people logging out of applications, as it is pretty reasonable for them to assume that if they close the browser that is the same thing. Certainly IE6 works this way. Apologies if this is fixed in version 0.7, but that version doesn't list NT as a supported platform and I daren't risk stuffing my machine by installing it as I am well behind with a website as it is. I guess I'd better get back to it.

Andy: That's a different bug. This bug (or RFE, rather) applies to Mozilla-the-application-suite, and requests that sessions expire when all browser windows pertaining to the session are closed (i.e., potentially sooner that all Mozilla windows are closed, or even before all browser windows are closed, but that's a matter of opinion).

*** Bug 200336 has been marked as a duplicate of this bug. ***

leaving the "when should a session be a session" stuff in bug 117222, we still have the issue of whether closing all browser windows should purge the session cookies. taking to evaluate

as darin pointed out in a discussion on IRC, to do this properly would require clearing memory cache and SSL session info, since sites may depend on the two being related. Doing that would probably require reworking how memory cache and SSL sessions are persisted, especially since they don't differentiate between mail/browser objects. His opinion, which I share, is that this isn't worth fixing at this stage of Seamonkey's existence. If it was good enough for NS 4.x and every Mozilla version until now, its good enough to keep. Since Seamonkey is on a sustained engineering path, and the move is towards standalone apps that do not share session data, I don't think fixing this is viable/desirable since it would introduce mostly unnecessary changes to components that don't need to be changed for anything except Seamonkey.

fair enough, just be aware that mozilla will therefore never make a decent kiosk substitute until this is fixed due to security concerns. mark

mconnor: why makes firefox fixing this easier? you still need to clear out memory cacha and ssl sessions. In firefox, cookies are also not bound to a window. So how do you know which cookies to remove?

mvl, this bug is mostly about clearing session cookies when all navigator windows are closed, we can easily dump memory cache/SSL sessions on Firefox since we don't have to figure out what belongs to mail and what belongs to browser. Mark, please clarify your comments. If you use just the browser, this isn't an issue assuming you close all windows. If you have a mail window open, the cookies don't get cleared. If you're using a kiosk setup, Firefox seems the better option in any case.

having thought way too much about this, I don't believe this is worth fixing. Neither does darin or dwitte, for that matter. Being that this not only would have to touch cookies, but SSL and cache, and given that only Seamonkey would benefit from it, there is no point in fixing this at this stage. In fact (although this is theory/speculation) to fix this for Seamonkey would create baggage for standalone apps like Firefox and Thunderbird. If you want session cookies gone when closing all of your browser windows, use Firefox.

I can accept that this won't be fixed, although I find the justification for it to be pretty objectionable - as phrased anyway. Saying "if you don't like it then use Firefox" is a little draconian. The last time I looked, mozilla.org had not discontinued, nor dropped support for, Seamonkey. With this attitude, we shouldn't be developing 1.8a at all - just FF. Much more reasonable, I think, would be to simply reassign the bug to "nobody" and just not work on it yourself... (The comment isn't meant personally, and I don't mean it to be a flame, I just find the viewpoint to be a little distressing.)

seamonkey isn't in active developement, its in sustained development, which means that seamonkey-specific changes that involve large engineering effort simply aren't being done. While we will continue to work on improving the base behind the suite, implementing changes across multiple modules for what is effectively a seamonkey-only bug just doesn't make sense. Leaving it for someone to work on is just an invitation to waste someone else's time. If someone has the skills and time to invest in integration work, there's a lot of bugs out there that need to be fixed. As for the Firefox comment, perhaps a better phrasing is "if you want browser and mail sessions kept separate, use standalone apps (i.e. Firefox/Thunderbird) instead of an integrated one (Seamonkey)" This bug at its core is about making the navigator windows act like a separate process from the mail process, and since as an organization we've gone beyond that in producing standalone apps instead of the monolithic suite, this bug is nowhere near as relevant/important as it would have been if we'd fixed it three years ago.

Cleaning up summary to say what comment 0 says. To keep me from wrting useless comments. (Wait, i just did that, and deleted it again...)

*** Bug 253546 has been marked as a duplicate of this bug. ***