User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150222232811 Steps to reproduce: 1. Create two fresh Firefox profiles, say, 'foo' and 'bar'. 2. Launch two parallel Firefox instances, one with `-P foo -no-remote`, other with `-P bar -no-remote`. 3. In one Firefox, paste this address into addressbar: `http://httpbin.org/cookies/set?foobar=secret` and hit Return. Page will redirect you to `http://httpbin.org/cookies`, and you should see JSON reply with list of cookies set — it could be empty or google analytics cookie might be set. Hit Shift+Refresh once, you'll see your new `foobar` cookie added. 4. Now in other Firefox instance, paste this address into addressbar: `http://httpbin.org/cookies` and hit Return. You will see JSON reply with your `foobar` cookie, despite the fact it shouldn't be there. You can refresh page as long as you want until you force cache reset with Shift+Refresh — after that JSON shows real cookie list. Actual results: Somehow two Firefox instances that are to be completely isolated one from another share the cached view of the page. I have noticed this when my cookies from Nightly build `eea6188b9b05` appeared in my regular Firefox 26 I use for browsing. I've thought some plugin causes this, so I created two fresh profiles and did it again. I'm using OS X 10.9.5. Expected results: Second Firefox instance should've show nothing unusual — at least, it must not show cookies set in totally irrelevant Firefox instance.
Also, I've tested the same setup with private browsing mode, it leaks both sides, from private to non-private, from non-private to private, and from private to private. To reproduce it's not required to close other window - you do Shift+Refresh in "source" window, then just hit Enter in the address bar with same URL, and content will sync.
...hit Enter in the "destination" window address bar, of course.
Setting following prefs and restarting browser had no effect of leaking: browser.sessionstore.max_resumed_crashes=0 browser.sessionstore.max_serialize_back=0 browser.sessionstore.max_serialize_forward=0 browser.sessionstore.max_tabs_undo=0 browser.sessionstore.max_windows_undo=0 browser.sessionhistory.max_total_viewers=0 browser.sessionhistory.max_entries=0 browser.cache.disk.enable=false browser.cache.memory.enable=false browser.cache.offline.enable=false network.http.use-cache=false devtools.cache.disabled=true
s/had no effect of leaking:/had no effect on leaking:/
Also reproduces in the same instance with private browsing mode. To reproduce: 1. Open Private browsing window. 2. Enter `http://httpbin.org/cookies/set?secret=meow` in the address bar, press Return. 3. JSON reply with set cookie will show. If it does not, Shift+Refresh. 4. You may now close private window, it will make no difference. 5. In regular window, enter `http://httpbin.org/cookies` in the address bar, press Return. 6. Voila, you see secret cookie. Also, in private browsing, when it first redirects to `/cookies` after setting secret cookie, it might also show cached view. I think it has the same reason as this bug.
Hi Ruby, Tried to test this issue on my end using latest Firefox Release (43.0) and latest Nightly (46.0a1-20151216030229) and could not reproduce it. Tested with two new profiles and also with private window and the results were the same, no secret cookie. :) Can you please test this issue again on your end using latest Firefox release or latest Nightly build (https://nightly.mozilla.org/) and report the results ? It may have been fixed along the way. Thanks, Paul
(In reply to Paul Oiegas from comment #6) > Hi Ruby, > > Tried to test this issue on my end using latest Firefox Release (43.0) and > latest Nightly (46.0a1-20151216030229) and could not reproduce it. Tested > with two new profiles and also with private window and the results were the > same, no secret cookie. :) > > Can you please test this issue again on your end using latest Firefox > release or latest Nightly build (https://nightly.mozilla.org/) and report > the results ? It may have been fixed along the way. > > > Thanks, > Paul Hello, Paul. I had just checked it with Firefox 42 and 43, reproduces in both. Hadn't checked with Nightly yet, will do now. Are you following instructions precisely (e.g. Shift+Reload part)?
(In reply to Paul Oiegas from comment #6) Yes, it also reproduces in Nightly. Here you have screencast of it reproducing both in 43 and Nightly - https://www.youtube.com/watch?v=hfQ1JfU2vug This was recorded on OS X 10.11.
Hi Ruby, I am using "Enter" key (return) to load the provided links and yes I am holding "Shift" key and click on Firefox "reload" button as you did on the provided screen recording, but I cannot reproduce your issue. I have made a screen recording too on my environment while trying to reproduce this on Firefox 43.0. Please let me know if I'm doing something wrong. https://www.youtube.com/watch?v=zDjD5hLp0pc There is one possibility that this issue could be caused by some installed extensions. Can you try this using Firefox in safe mode ? You can also try to Refresh Firefox to factory defaults as a last measure, if your browser was not installed right before testing (I saw that Firefox was mounted while recording). If you don't know how to enter in safe mode or to refresh the browser, here is a link that will help. https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems Thanks, Paul
(In reply to Paul Oiegas from comment #9) Hi Paul, What you have seen in my screencast was clean install of Firefox in separate user profile on dedicated machine. Firefox did not exist there before, and it's physically different computer from one where the issue was initially observed. Both browsers were installed, they weren't run from .dmg image. There were no extensions, and only plugins that Firefox ships with, nothing extra installed. As I had just verified per your request, additionally providing `--safe-mode` switch does not affect reproduceability of a bug. Also, for the sake of eliminating possible platform-specific explanations, I had installed Windows XP in virtual machine environment, installed Firefox 43 there, followed my guides and here you have a screencast of it reproducing: https://www.youtube.com/watch?v=nu4UGuTk0YY It's definitely not related to something specific to my computer. If you have any ideas what experiments I should conduct to find out differences between our computers, I will gladly assist.
I don't have any other ideas in mind right now, but I am assigning this issue to a related component in order to involve the development team. Maybe someone with more experience on this area could help us with some informations or suggestions. If anyone thinks that this is not the right component for this issue, please feel free to change it with a more appropriate one. Thanks, Paul
Component: Untriaged → Networking: Cookies
From watching the video I think you might be using the wrong command line switch. Its "-no-remote", but it seems you were using "--no-remote". Note the single dash. (Yes, our command line switches don't match normal linux conventions and yes its annoying you don't get an error for unknown switches.) So I think your second execution was actually opening in the same profile as the first execution. Can you try again with -no-remote?
(In reply to Ben Kelly [:bkelly] from comment #12) Sure, I had just checked. It reproduces in both OS X and Windows XP with "-no-remote" as well as "--no-remote". Also, from http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#466 I can tell that Firefox recognizes both -single-dash and --double-dash notation as same switch, so that check was pointless but I did it anyway. It worked.
Fair enough. I just ran through the same 4 or 5 times trying to reproduce, though, and I can't get it to trigger.
Hi Ruby, I have just tried to reproduce this on latest Firefox release (44.0.1) on a new MacBook Pro laptop with freshly installed Mac OS X 10.11.2 and still no luck. Considering that you still encountered this issue while I could not reproduce it, all I can do is to mark this as NEW. Maybe someone with more experience on this area could look into this and share an opinion. Thanks, Paul
Status: UNCONFIRMED → NEW
Ever confirmed: true
honza, is there logging that we could have the reporter get to see if he really is seeing cache hits across profiles somehow?
It could happen that OSX, or just that one machine the reporter has, may return some general folder for NS_APP_CACHE_PARENT_DIR or NS_APP_USER_PROFILE_LOCAL_50_DIR calls. Same directory for both processes used for the cache. Ruby, can you in both instances check about:cache, and under the "disk" part check what is the "Storage disk location"? Then please add the directories from both windows here to a bugzilla comment, unscrambled in any way. Seems like the two profiles are regular profiles created with the profile manager, right? I've recently introduced a feature to our NSPR logging that adds PID automatically to the file. Let the reporter do the following setup: set NSPR_LOG_FILE=/some/path/nspr-%PID.log set NSPR_LOG_MODULES=timestamp,cache2:5,nsHttp:5 then run. And let's see what really happens. Unfortunately, we don't log the cache dir, we can only see if the entries are found or not.
Flags: needinfo?(honzab.moz) → needinfo?(malicious.wizard)
It stopped reproducing for some reason on all affected machines, including virtual machines that were not updated (or launched) at all. I don't know how could it happen, given that bugs usually don't fix themselves occasionally, but reinstalling fresh Windows XP on virtual machine with Firefox 36.0 no longer reproduces the issue. Too bad I could not find the cause :(
thanks for looking.. please open a new bug if it recurs
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.