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

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect, P2)

Description

[mario garbi]

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:
http://mozmill-ci.blargon7.com/#/functional/report/a1b02004612785c13cf7c6bf1e56a51d

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Are you able to replicate this locally? Please follow the usual steps when test failures are discovered.

Comment 2

[Andrei Eftimie]

This might be a dupe of bug 873974

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

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.

Comment 4

[Daniela Petrovici]

Started happening on Aurora DE with Windows 7 x64:
http://mozmill-ci.blargon7.com/#/functional/report/593227b0561e6d84f2e52c84222a0f2c

Comment 5

[Cosmin Malutan, [:cosmin-malutan]]

Happened today on Aurora IT with Windows Vista x86:
http://mozmill-daily.blargon7.com/#/functional/report/5aa1ca5e7015e3740d269dc947c0cab7

Comment 6

[Andreea Matei [:AndreeaMatei]]

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.

Comment 7

[mario garbi]

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

http://mozmill-daily.blargon7.com/#/functional/report/bccc2ea9ac1e478fa074c699d8ac7606

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Andreea, have you had time to check what's going on here?

Comment 9

[Andreea Matei [:AndreeaMatei]]

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

[Andreea Matei [:AndreeaMatei]]

So what happens here is that we don't get through the if (deviceID == "memory") code at all when we fail:
http://hg.mozilla.org/qa/mozmill-tests/file/default/tests/functional/testPrivateBrowsing/testAboutCache.js#l44

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?

Comment 11

[u279076]

Can we please disable this test while the cause is investigated? It's our #8 top failure on Firefox 25 right now.

Comment 12

[Andrei Eftimie]

(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)

Comment 13

[Honza Bambas (:mayhemer)]

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

Comment 14

[Honza Bambas (:mayhemer)]

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.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Not sure I can give a valuable input here after Honza's comments. Most likely Josh could help us in getting this identified.

Comment 16

[Honza Bambas (:mayhemer)]

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!

Comment 17

[Josh Matthews [:jdm]]

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.

Comment 18

[Andrei Eftimie]

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 )

Comment 19

[Honza Bambas (:mayhemer)]

Just for info, you can (actually should) use the cache API landed at 913807.  I can provide info if needed.

Comment 20

[Andreea Matei [:AndreeaMatei]]

Attachment: 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.

Comment 21

[Andrei Eftimie]

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)

Comment 22

[Andrei Eftimie]

Ok, lets close this bug.

Please reopen if this fails again on one of the branches where this test is still running.