Test failure "Memory cache has no entries after PB mode - 'undefined' should equal '0'" in /testPrivateBrowsing/testAboutCache.js



Mozilla QA
Mozmill Tests
5 years ago
4 years ago


(Reporter: mario garbi, Assigned: AndreeaMatei)



Firefox Tracking Flags

(firefox24 unaffected, firefox25 disabled, firefox26 disabled, firefox27 disabled, firefox-esr17 unaffected, firefox-esr24 unaffected)


(Whiteboard: [mozmill-test-failure], URL)


(1 attachment)



5 years ago
This started failing on Windows 6.0, 6.1 and 6.2 with both en-US and fr locales of Firefox 25.0a1 as can be seen in the URL link.

Sample report on Windows 8 (x86) with Firefox 25.0a1 fr:


5 years ago
status-firefox25: --- → affected
Are you able to replicate this locally? Please follow the usual steps when test failures are discovered.
Priority: P3 → P2

Comment 2

5 years ago
This might be a dupe of bug 873974
Whiteboard: [mozmill-test-failure] → [mozmill-test-failure][dupeme]
The failure message is different, so although they may be related I would not consider this a dupe. This is regarding the memory cache being undefined. Bug 873974 is regarding the disk cache being 1.


5 years ago
Whiteboard: [mozmill-test-failure][dupeme] → [mozmill-test-failure]

Comment 4

4 years ago
Started happening on Aurora DE with Windows 7 x64:
status-firefox24: --- → affected
Hardware: x86 → All
Happened today on Aurora IT with Windows Vista x86:

Comment 6

4 years ago
I will try to reproduce this and see what happens. 
Failed over the weekend as well on Linux 12.10, Windows Vista, 7 and 8, with Nightly fr and en-us locales and once with Aurora - de locale.
Assignee: nobody → andreea.matei
Depends on: 873974


4 years ago
No longer depends on: 873974

Comment 7

4 years ago
Happened again today on Windows 8x64 with Firefox 26.0a1 (26.0a1, fr, 20130806104538)

status-firefox26: --- → affected
Andreea, have you had time to check what's going on here?

Comment 9

4 years ago
Yes, I was able to reproduce this before my PTO, rarely from time to time, what I found it would help is a waitFor() to make sure the memory entry count does get loaded (meaning is not undefined). I remember when I created the test, Josh mentioned there's no guarantee the memory entries will update immediately.

I will add the patch tomorrow after leaving it run over night to make sure the failure is gone.

Comment 10

4 years ago
So what happens here is that we don't get through the if (deviceID == "memory") code at all when we fail:

I also replaced the visitDevice function with a switch to go through all cases (disk, memory, offline) and when it failed only disk and offline were dumped.

I'm not sure how they interact with each other, if it takes some time for the memory entries to be shown after we exit private mode. Josh, would you be able to provide some info on this?

Besides this, I found from Manuela (QA team) that she created a similar chrome test in bug 880621, shall we still keep ours?
Flags: needinfo?(josh)
Flags: needinfo?(hskupin)
Can we please disable this test while the cause is investigated? It's our #8 top failure on Firefox 25 right now.

Comment 12

4 years ago
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #11)
> Can we please disable this test while the cause is investigated? It's our #8
> top failure on Firefox 25 right now.

We might disable this test altogether since it appears to be covered by a mochitest as Andreea pointed out in bug 880621

**Seeing the new comments there, we might need to rewrite it altogether for a new cache backend?

Honza, has the new cache backend landed?
Could that affect our failures here?
(Seems unlikely since we started failing in the 1st of July on Firefox 25)
Flags: needinfo?(honzab.moz)
On the gum tree (where HTTP cache v2 is being grown - and getting ripe!) I've fixed browser/components/privatebrowsing/test/browser/browser_privatebrowsing_cache.js to make it work better, see [1].

The problem with that test were that not just the page requests were made, but also savebrowsing, favicon etc requests were active during the checks.  Also, there was no good distinction of private and in-memory (no-store) content when visiting the cache using the old cache API, so things got mixed during checks.  Only the new cache API is able to correctly iterate exactly what you are interested in.

Could this test problems be the same issue?

And yes, I think the new cache might be a solution here.  It is tracked in bug 913807 to land (soon!) preffed off (new API just wraps the old) and in bug 913808 to be preffed on (there are few bugs blocking it, see its dep list).

[1] https://bugzilla.mozilla.org/attachment.cgi?id=802444&action=diff#a/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_cache.js_sec1
Flags: needinfo?(honzab.moz)
Looking at the report and into the test, yes, this is clearly the same issue.  Clearly, there is some request with no-store or with inhibit-persistent-caching made and you find during the check.

The test is wrong.  Services.cache.visitEntries is not the way to detect (or not detect) PB entries.
Not sure I can give a valuable input here after Honza's comments. Most likely Josh could help us in getting this identified.
Flags: needinfo?(hskupin)
You may rather try to open the entry (entries) you don't expect to be there after PB exit using nsICacheSession.  Open them under "HTTP-memory-only-PB" client id, storagePolicy == STORE_IN_MEMORY and access == nsICache::ACCESS_READ (only read).  If you get it, test has failed.  If you get CACHE_ENTRY_NOT_FOUND, you are OK.

See how complicated it is? :)

New cache is way simpler at this!
It looks like Honza has provided the help necessary here. Ping me again if there's something in particular I can answer; last time was in the middle of a vacation period and it got lost in the shuffle.
Flags: needinfo?(josh)

Comment 18

4 years ago
Andreea please check if we have any additional coverage in our test besides what is being tested in the test from bug 880621

As discussed in our last Ask an Expert meeting, if we don't provide any additional checks, we might disable the mozmill test.

However we might want to keep it for 24 and ESR24 so also check if you can fix it with Honza's additional information.

We still see this failure pretty often.
(eg. http://mozmill-daily.blargon7.com/#/remote/report/1039ea48a9d69a5a1cc4fd228c860acf )
status-firefox27: --- → affected
status-firefox-esr24: --- → affected
Flags: needinfo?(andreea.matei)
Just for info, you can (actually should) use the cache API landed at 913807.  I can provide info if needed.

Comment 20

4 years ago
Created attachment 809103 [details] [diff] [review]
patch v1

Test is the same as in bug 880621. That one is landed from beta up, tested the patch and it applies cleanly on all.

For release, esr17 and esr24, I can't use the new API as it's not backported. But also I haven't seen failures on CI for these branches, I believe we're safe there.
Attachment #809103 - Flags: review?(andrei.eftimie)
Flags: needinfo?(andreea.matei)


4 years ago
status-firefox24: affected → unaffected
status-firefox-esr17: --- → unaffected
status-firefox-esr24: affected → unaffected

Comment 21

4 years ago
Comment on attachment 809103 [details] [diff] [review]
patch v1

Review of attachment 809103 [details] [diff] [review]:

Looks good, removed:
http://hg.mozilla.org/qa/mozmill-tests/rev/c88b5b2ce00e (default)
http://hg.mozilla.org/qa/mozmill-tests/rev/4155a6e8a4ab (mozilla-aurora)
http://hg.mozilla.org/qa/mozmill-tests/rev/9aa4e226ea2b (mozilla-beta)
Attachment #809103 - Flags: review?(andrei.eftimie)
Attachment #809103 - Flags: review+
Attachment #809103 - Flags: checkin+

Comment 22

4 years ago
Ok, lets close this bug.

Please reopen if this fails again on one of the branches where this test is still running.
Last Resolved: 4 years ago
status-firefox25: affected → disabled
status-firefox26: affected → disabled
status-firefox27: affected → disabled
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.