User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36 Steps to reproduce: 1. Make sure that in non private mode the user is NOT logged into the website to which the content_script applies. 2. Open a private browsing window and navigate to the website where the content_script is active. 3. In the private window log into the website with account A. 4. Trigger the event that causes ajax calls to be made that need a session in order to return the correct data. Look at the result of the ajax calls. 5. Now in the non private (regular?) window log into the website with account B. 6. Repeat step 4. Actual results: The calls in step 4. failed the calls in step 7 return information belonging to account B. Expected results: In both step 4 and in step 6 the ajax calls should return data based on the session for the that is active in the private browsing window, NOT based on the sessions active for that same website in the regular window. Data for account B should never be the result.

What Firefox version are you seeing this with? This should have been fixed in Firefox 50.

(In reply to Kris Maglione [:kmag] from comment #1) > What Firefox version are you seeing this with? This should have been fixed > in Firefox 50. we actually started to get reports about this since version 50 of firefox. Which threw us into a loop because the extension I am working on had a release on pretty much the same day and we couldn't reproduce it until someone mentioned it only being an issue in private browsing mode. I didn't include that initially as I am not 100% certain if it is an issue since version 50 as not many users use the extension solely in private browsing. Which means they usually have logged into the website in regular mode as well. Which means the calls will work in private mode, just possibly returning data belonging to a different user.

Apparently these are set from the load group rather than the principal, and we don't set a load group for requests from content scripts.

Comment on attachment 8814262 [details] Bug 1319536: Part 1 - Take private browsing ID from load info when load context is unavailable. https://reviewboard.mozilla.org/r/95496/#review95740

Comment on attachment 8814263 [details] Bug 1319536: Part 2 - Test that requests from private prowsing content scripts use private browsing credentials. https://reviewboard.mozilla.org/r/95498/#review95742

https://hg.mozilla.org/integration/mozilla-inbound/rev/ce6bd69e09fb1927631d5a4aa0b66913e17a90a2 Bug 1319536: Part 1 - Take private browsing ID from load info when load context is unavailable. r=ehsan https://hg.mozilla.org/integration/mozilla-inbound/rev/d0987b1b6e085e275e78bda81c2ef08e7ba87a00 Bug 1319536: Part 2 - Test that requests from private prowsing content scripts use private browsing credentials. r=aswan

Comment on attachment 8814262 [details] Bug 1319536: Part 1 - Take private browsing ID from load info when load context is unavailable. Approval Request Comment [Feature/regressing bug #]: Unclear, but this appears to be a regression in Firefox 50 [User impact if declined]: This bug causes content scripts running in private browsing windows to make non-private requests. This could cause anything from minor unexpected behavior, to leaking data or credentials from non-private contexts to private ones, or vice versa. [Describe test coverage new/current, TreeHerder]: New tests have been added for this behavior. [Risks and why]: Low. This is a minimal change, which should have no effect except on requests which a) have load info, b) have no load context, and c) were made from a principal with a private browsing origin. Only internal or extension code should ever encounter this situation, and none of it should be relying on the previous, incorrect behavior. [String/UUID change made/needed]: None.

https://hg.mozilla.org/mozilla-central/rev/ce6bd69e09fb https://hg.mozilla.org/mozilla-central/rev/d0987b1b6e08

Hi Brindusa, Can you help find someone to verify if this is fixed on latest nightly?

(In reply to Kris Maglione [:kmag] from comment #9) > [Describe test coverage new/current, TreeHerder]: New tests have been added > for this behavior. > I see that new tests were added to cover this scenario. Is it manual testing still needed for this? If yes, Kris, could you help us with some exact steps to verify this bug?

(In reply to Brindusa Tot[:brindusat] from comment #12) > I see that new tests were added to cover this scenario. Is it manual testing > still needed for this? It's probably still worth manually testing, yes. > If yes, Kris, could you help us with some exact steps to verify this bug? It would probably be best to have the reporter confirm that this is fixed, but I initially tested it by: 1) Create an extension that loads a content script into a site that requires login. Have that script make an XMLHttpRequest to the page it's loaded into, and log the response text to the console. 2) Log into that site in a non-private window. 3) Open a private window, and load the same site. 4) Check that the logged response shows the logged-in user from the non-private window, but not from the private one. I used https://www.google.com/, but any site that requires login and displays a username should work.

Hi Brindusa, According to comment #13, can you help verify this based on the STR?

I don't have the knowledge to create a extension mention in Step 1 from comment 13. Creesch, could you please verify if this issue is fixed on latest Nightly 53.0a1?

(In reply to Brindusa Tot[:brindusat] from comment #15) > I don't have the knowledge to create a extension mention in Step 1 from > comment 13. > > Creesch, could you please verify if this issue is fixed on latest Nightly > 53.0a1? Will do so as soon as I can get to a pc where I can use nightly.

(In reply to Brindusa Tot[:brindusat] from comment #15) > I don't have the knowledge to create a extension mention in Step 1 from > comment 13. > > Creesch, could you please verify if this issue is fixed on latest Nightly > 53.0a1? Can confirm it is fixed in 53.0a1.

Thanks

Comment on attachment 8814262 [details] Bug 1319536: Part 1 - Take private browsing ID from load info when load context is unavailable. let's take this private browsing fix into aurora52 (two patches, with part 2 adding tests)

Comment on attachment 8814262 [details] Bug 1319536: Part 1 - Take private browsing ID from load info when load context is unavailable. Fix an issue related to private browsing. Beta51+. Should be in 51 beta 7.

https://hg.mozilla.org/releases/mozilla-aurora/rev/314b4c10adef https://hg.mozilla.org/releases/mozilla-aurora/rev/3d17099df5f3

https://hg.mozilla.org/releases/mozilla-beta/rev/62adc52cbc74 https://hg.mozilla.org/releases/mozilla-beta/rev/6509f723f6e4

Comment on attachment 8814262 [details] Bug 1319536: Part 1 - Take private browsing ID from load info when load context is unavailable. Fixed already in 51, which is now on the mozilla-release branch.