937380 - forgetaboutsite/test/browser/browser_clearplugindata.js fails when browser-chrome tests are split into chunks

Status: RESOLVED FIXED

(Toolkit :: Data Sanitization, defect)

Description

[Jonathan Griffin (:jgriffin)]

When browser-chrome tests are split into chunks (bug 819963), the test /forgetaboutsite/test/browser/browser_clearplugindata.js fails with:

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/forgetaboutsite/test/browser/browser_clearplugindata.js | uncaught exception - TypeError: p.setSitesWithData is not a function at http://mochi.test:8888/browser/toolkit/forgetaboutsite/test/browser/browser_clearplugindata.html:17
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/forgetaboutsite/test/browser/browser_clearplugindata.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/forgetaboutsite/test/browser/browser_clearplugindata.js | Found a tab after previous test timed out: http://mochi.test:8888/browser/toolkit/forgetaboutsite/test/browser/browser_clearplugindata.html

full log:  https://tbpl.mozilla.org/php/getParsedLog.php?id=30437270&tree=Cedar&full=1

Possibly, it's depending on something from an earlier test which is now running in a different chunk.

Comment 1

[Phil Ringnalda (:philor)]

My policy is to never understand something when I can instead cargo-cult it, and since every other use of setSitesWithData comes after a p.setSitesWithDataCapabilities(true) or p.setSitesWithDataCapabilities(false), I wonder whether that would make it stop failing.

Comment 2

[Benjamin Smedberg]

I suspect that this test relies on the test plugin being enabled, but doesn't explicitly enable it, and is relying on some prior test enabling it. There are several versions of setTestPluginEnabledState in the tree which do this correctly.

Comment 3

[Phil Ringnalda (:philor)]

Nice. I can see where http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/browser/browser_CTP_plugins.js#223 would be leaking STATE_ENABLED, but mozapps/extensions/ is the last thing to run in one-hunk browser-chrome, so it can't be relying on that. Offhand, I don't see any other tests that aren't saving off the initial state with a setTestPluginEnabledState, even if they do later directly set a state.

Comment 4

[Drew Willcoxon :adw]

Attachment: patch

Passes locally with this.  Benjamin, would you mind reviewing?

Comment 5

[Drew Willcoxon :adw]

Attachment: patch 2

Sorry, careless mistake in the previous patch.

Comment 6

[Benjamin Smedberg]

Comment on attachment 8334816 [details] [diff] [review]
patch 2

Not sure about the mochitest-browser tests... I finally figured out what's leaking enabled states in mochitest-chrome tests last week; haven't filed/fixed yet though.

Comment 7

[Drew Willcoxon :adw]

https://hg.mozilla.org/integration/fx-team/rev/15e0829b8c48

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/15e0829b8c48