how do i make xul's <browser> to have its own profile?

Question

I'm using two <browser>s in a xul that should use a different profile each. both are navigating the same site (it's a webapp) but they should handle their session individually. currently if I set a cookie in one of them, it will be available on the second <browser> as well. is there a way to have them totally independent?

Answer 1

<browser>s and networking stuff are mostly independent. That is: There is one cookie service and one HTTP "service" that uses the cookie service... Or one profile if you prefer that. You cannot run two profiles in the same process...

Well, actually now there are two sets of cookies (and caches, etc. - or user state in general). The regular one and a volatile one for private browsing. If you're really only after two different <browser>s and not n>=2, then toggling one of the <browser>s into private browsing mode may suffice for your use case. In general it should be possible to set PrivateBrowsingUtils.privacyContextFromWindow(window).usePrivateBrowsing = true;, where window is the .contentWindow of your <browser>. Use Cu.import("resource://gre/modules/PrivateBrowsingUtils.jsm") to load the utility code module in your window first ;) It may be possible to get some inspiration from the great Private Tab add-on in this area, as this is essentially what that add-on does: Put <browser>s with different private browsing mode and hence user state into the same window.

Update 1: A private session is basically a regular session, separately keeping track of cookies, localstorage, caches etc, but is only kept in memory and never written to disk. As such it will go away once the application exits. Additionally, once the last private window context closes (well, the nsIDocShell associated with it), the "last-pb-context-exited" notification will be sent, which causes the private session to be dropped as well. If you run into problems where the private session vanishes prematurely, just keep another (hidden) private <browser> around somewhere.

If this does not suffice, then consider running two separate Firefox instances. The -profile <path> and -no-remote (to run sessions in parallel) switches are your friends here.

If you're only after cookies, it also would be possible to manipulate the cookies requests originating from your <browser>s by getting the <browser> first if any, and then adding Cookie headers as appropriate. Of course, this will not affect other stuff the site may use such as localstorage or IndexedDB, so it might not be sufficient.

If all of the above doesn't really work for you, then I guess you're out of luck...

It might be possible to do more fancy stuff with e10s (multi-process Firefox) in the future, but IIRC using two profiles in one application instance is not supported or possible with it nor planned (judging from Nightly, where there is already experimental e10s support).