Closed Bug 972347 Opened 10 years ago Closed 10 years ago

Disk cache entries from PB window also appear in the regular window

Categories

(Firefox :: Private Browsing, defect)

Product:
Firefox
Component:
Private Browsing
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: manuela.muntean, Unassigned)

Details

Attachments

(1 file)

about_cache.zip
89.31 KB, application/x-zip-compressed
Details 
Reproducible with:

- latest Nightly 30.0a1 (build ID: 20140213030201)
- latest Aurora 29.0a2 (build ID: 20140213004002)
- latest Beta - Firefox 28 beta 2
- Firefox 26
- Firefox 27

STR

1. Create a new profile and start Firefox
2. Clear cache under "Firefox button | History | Clear Recent History" or "Tools | Clear Recent History" or "Ctrl/Cmd+Shift+Del" - select "Everything" from drop down list, check all the options from "Details" and click "Clear Now"
3. Open "about:cache" in URL bar (Disk cache should report 0 KiB and have no entries)
4. Open a private window, load google.com and search for "book"
5. In the private window, open "about:cache" and click "List cache entries" under Disk Cache (entries from related visited sites are shown)
6. Close the private window
7. Return to the normal window and check "about:cache"

ER: after step 7, Disk cache should report 0 KiB and have no entries
 
AR: after step 7, Disk cache doesn't report 0 KiB and shows the same number of entries shown at step 5, in the private window


Note: this issue is not a regression since it's also reproducible with Firefox 20.0.1 and the feature was released with Firefox 20
Depends on: pbchannelfail
OS: Windows 7 → All
Hardware: x86_64 → All
this really shouldn't happen - michal can you verify?
Flags: needinfo?(michal.novotny)
i wonder if you still had a private window hanging around when you thought they were all closed.. that would prevent the "clear the pb cache" event from going out.. this could even be some kind of internal hanging reference not visible to you.. I guess I would start with the content folks with that hypothesis.
Preemptively flagging for test coverage. Mihaela, can you please investigate what, if any, tests exist for this. If none exist please work on getting something in place after this is resolved.

Thanks
Flags: in-testsuite?
Flags: in-qa-testsuite?(mihaela.velimiroviciu)
What are the entries that you see here?  Here is what I get when I try to reproduce the bug:

Key 	Data size 	Fetch count 	Last modified 	Expires
anon&id=1392312726&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-13 12:33:57 	2014-02-19 11:26:12
anon&id=1392312728&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-13 12:33:57 	2014-02-19 09:42:18
https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/30.0a1/Firefox/20140210204404/Darwin_x86_64-gcc3/en-US/default/Darwin%2013.0.2/default/default/1/68/24/ 	112813 bytes 	1 	2014-02-13 12:33:58 	2014-02-13 12:53:17
anon&id=1392312727&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-13 12:33:57 	2014-02-19 10:50:52
anon&id=1392312725&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-13 12:33:47 	2014-02-17 12:33:47

The http://clients1.google.com/ocsp entry is a bit problematic, but I think Brian is going to kill oscp very soon.  The rest of the entries have nothing to do with what I did on google.com.
Flags: needinfo?(manuela.muntean)
Ehsan, take out the AMO entry and I see the same entries as you posted when testing against google search.  

I have tried with several other sites and can not reproduce this bug.
(In reply to Patrick McManus [:mcmanus] from comment #1)
> this really shouldn't happen - michal can you verify?

I can see only the cached OCSP response. I don't know this code very well but I think the OCSP request isn't loaded within the same load group as the channel that initiated the OCSP request, so this seems to be expected behavior.
Flags: needinfo?(michal.novotny)
(In reply to comment #7)
> (In reply to Patrick McManus [:mcmanus] from comment #1)
> > this really shouldn't happen - michal can you verify?
> 
> I can see only the cached OCSP response. I don't know this code very well but I
> think the OCSP request isn't loaded within the same load group as the channel
> that initiated the OCSP request, so this seems to be expected behavior.

It's more known than expected, I would say.
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailapocalypse) from comment #5)
> What are the entries that you see here?  Here is what I get when I try to
> reproduce the bug:
> 
> Key 	Data size 	Fetch count 	Last modified 	Expires
> anon&id=1392312726&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-13
> 12:33:57 	2014-02-19 11:26:12
> anon&id=1392312728&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-13
> 12:33:57 	2014-02-19 09:42:18
> https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-
> 13a3a9e97384%7D/30.0a1/Firefox/20140210204404/Darwin_x86_64-gcc3/en-US/
> default/Darwin%2013.0.2/default/default/1/68/24/ 	112813 bytes 	1 
> 2014-02-13 12:33:58 	2014-02-13 12:53:17
> anon&id=1392312727&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-13
> 12:33:57 	2014-02-19 10:50:52
> anon&id=1392312725&uri=http://clients1.google.com/ocsp 	463 bytes 	1 
> 2014-02-13 12:33:47 	2014-02-17 12:33:47
> 
> The http://clients1.google.com/ocsp entry is a bit problematic, but I think
> Brian is going to kill oscp very soon.  The rest of the entries have nothing
> to do with what I did on google.com.

I've repeated the test with Firefox 27.0.1 on Win 8 64-bit, and this is what I get: 


anon&id=1392360190&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-14 08:46:30 	2014-02-18 08:46:30
https://sb-ssl.google.com/safebrowsing/newkey?client=navclient-auto-ffox&appver=27.0.1&pver=2.2 	154 bytes 	1 	2014-02-14 08:44:49 	1970-01-01 02:00:00
anon&id=1392360189&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-14 08:46:29 	2014-02-18 08:46:29
anon&id=1392360188&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-14 08:46:27 	2014-02-18 08:46:27
anon&id=1392360192&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-14 08:46:40 	2014-02-18 08:46:39
anon&id=1392360191&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-14 08:46:40 	2014-02-18 08:46:39
Flags: needinfo?(manuela.muntean)
Attached file about_cache.zip — 
I've also checked with the Task Manager, and there is only one Firefox process active after closing the PB window.

Please see the attachement containing the "about:cache" in the normal and PB windows.
There is a browser chrome tests which verifies the disk cache (and is available across all branches):
http://mxr.mozilla.org/mozilla-central/source/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_cache.js#5

I checked TBPL and the tests passes on all branches:
https://tbpl.mozilla.org/?tree=Mozilla-Release&rev=66b0d478ee77
https://tbpl.mozilla.org/?tree=Mozilla-Beta&rev=58908dc356c1
https://tbpl.mozilla.org/?tree=Mozilla-Aurora&rev=6c70ddf78844
https://tbpl.mozilla.org/?rev=d275eebfae04

Anthony,I'm not sure which flag (in-testsuite/in-qa-testsuite) applies for this test...
anon&id=1392371241&uri=http://clients1.google.com/ocsp appears in disk cache after a while, without navigating to any page.

STR:
1. Launch the browser
2. Clear all cache entries
3. Leave the browser window opened for a while without navigating to any page (I forgot it open for more than 2 hours)
4. Check disk cache

Result: anon&id=1392371241&uri=http://clients1.google.com/ocsp appears among the disk cache entries.

Here is all the content of my disk cache (browser window left open for a long time, no navigation:

Key 	Data size 	Fetch count 	Last modified 	Expires
anon&id=1392371238&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-14 13:50:54 	2014-02-20 13:07:20
anon&id=1392371235&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-14 13:01:55 	2014-02-20 10:10:20
anon&id=1392371241&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-14 14:16:04 	2014-02-18 14:16:03
https://www.google.com/favicon.ico 	982 bytes 	1 	2014-02-14 12:07:59 	2014-02-21 22:06:32
anon&id=1392371239&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-14 13:50:54 	2014-02-20 11:08:36
anon&id=1392371234&uri=http://ocsp.digicert.com/ 	471 bytes 	1 	2014-02-14 13:01:55 	2014-02-20 11:03:00
anon&id=1392371232&uri=http://clients1.google.com/ocsp 	463 bytes 	1 	2014-02-14 12:48:07 	2014-02-18 12:48:07
The results from comment #12 were obtained on Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0, build id 20140213030201 (Ubuntu 13.04 x86)
(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #11)
> Anthony,I'm not sure which flag (in-testsuite/in-qa-testsuite) applies for
> this test...

in-testsuite applies for these tests, however if the tests are passing they failed to catch this bug so we need more tests.
Comment 12 is fine, because we can connect to google's servers for things such as the search bar, the safebrowsing service, etc. which means that you will have stuff from google.com in your disk cache after a while.

Comment 9 is also fine, since none of those cache entries are coming from the private window.

Doesn't look like there is a bug here after all.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
(In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness, emailapocalypse) from comment #5)
> 
> The http://clients1.google.com/ocsp entry is a bit problematic, but I think
> Brian is going to kill oscp very soon.  

that plan is for DV - OCSP for EV is going to be with us for a little while longer so it might make sense to find a way to plug this private browsing interaction.
Dropping test requests given this bug is invalid.
Flags: in-testsuite?
Flags: in-qa-testsuite?(mihaela.velimiroviciu)
(In reply to Patrick McManus [:mcmanus] from comment #16)
> (In reply to :Ehsan Akhgari (needinfo? me!) (slow responsiveness,
> emailapocalypse) from comment #5)
> > 
> > The http://clients1.google.com/ocsp entry is a bit problematic, but I think
> > Brian is going to kill oscp very soon.  
> 
> that plan is for DV - OCSP for EV is going to be with us for a little while
> longer so it might make sense to find a way to plug this private browsing
> interaction.

Oh right, thanks for pointing this out!

I'm pretty sure there was a bug on file about this, but can't find it right now.  Josh?
Flags: needinfo?(josh)
No longer depends on: pbchannelfail
I also remember seeing this before and discussing it, but can't find any record.
Flags: needinfo?(josh)
Unable to see the private browsing cache get cleared on closing the private browsing tabs

Open the browser (about:cache) and ensure the disk cache reads as "0" Kib
Open the Private browsing and then browse the sites and ensure the Disk cache shows some Kib
close the Private browsing tabs and check the disk cache

Actual : The disk cache doesn't reset to "0" Kib

Expected : Disk cache should reset to "0" Kib
(In reply to comment #20)
> Unable to see the private browsing cache get cleared on closing the private
> browsing tabs

Open the browser (about:cache) and ensure the disk
> cache reads as "0" Kib
Open the Private browsing and then browse
> the sites and ensure the Disk cache shows some Kib
close the Private
> browsing tabs and check the disk cache

Actual : The disk cache
> doesn't reset to "0" Kib

Expected : Disk cache should
> reset to "0" Kib

No, it shouldn't.  See the previous comments on the bug please.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: