519799 - Fennec - mochitest chrome failure - test_bug396519.xul

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Doug Turner (:dougt)]

17 failures on docshell/test/chrome/test_bug396519.xul.  The cause is how Fennec changed the number of maximum viewers from unlimited (e.g. -1) to 1.  

Setting the pref:

pref("browser.sessionhistory.max_total_viewers", -1);

The test case does not attempt to understand that a browser may only have one viewer. Maybe we can do this ahead of the test case being run.

Comment 1

[Doug Turner (:dougt)]

ajschult - is this okay if we do something like this?

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

we can adjust that in the automation.py settings by adding a user_pref like this:

http://mxr.mozilla.org/mozilla-central/source/build/automation.py.in#236

Comment 3

[Doug Turner (:dougt)]

sure, there are places we can add it to our automation, but I do not think we should add it there (as it will change the behavior for _ALL_ tests run).  I would like to hear from ajschult.

Comment 4

[Andrew Schultz]

Right... your app runs with the different pref and the test is trying to test that content viewers are evicted appropriately for a different value of the pref.

Within Fennec, you might be more interested to know that content eviction happens properly (1 or 0 viewer cached) in your app than that content eviction would happen correctly if someone changed the pref back to the FF default value.  If so, you'd need to fix the testcase to check for correct behavior in your situation.

I hardcoded all the true/false values because there's no simple pattern.  But I think the testcase could be extended to handle any # of max_total_viewers by numbering the |true| entries from 1 to 3 in terms of "this content viewer would exist if max total content viewers is at least x".  Ideally, you'd need to be able to determine the actual max, which is either the pref value or (if the pref is -1) dependent on the amount of physical memory.  nsSHistory has a method to expose the actual value, but nsISHistory doesn't, so it's not really available.  I guess we could assume it's at least 3 if the pref is -1 (which would be true if there's at least 256MB RAM).

Does that sound better than the alternatives?

Comment 5

[Andrew Schultz]

Attachment: patch

like this?
It'd help if you could test this in Fennec

Comment 6

[BMO Automation]

Closing all opened bug in a graveyard component