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

RESOLVED FIXED in mozilla28



5 years ago
5 years ago


(Reporter: jgriffin, Assigned: adw)


Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



5 years ago
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:

Possibly, it's depending on something from an earlier test which is now running in a different chunk.
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.
Flags: needinfo?(benjamin)

Comment 2

5 years ago
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.
Flags: needinfo?(benjamin)
Nice. I can see where 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

5 years ago
Created attachment 8334815 [details] [diff] [review]

Passes locally with this.  Benjamin, would you mind reviewing?
Attachment #8334815 - Flags: review?(benjamin)

Comment 5

5 years ago
Created attachment 8334816 [details] [diff] [review]
patch 2

Sorry, careless mistake in the previous patch.
Attachment #8334815 - Attachment is obsolete: true
Attachment #8334815 - Flags: review?(benjamin)
Attachment #8334816 - Flags: review?(benjamin)

Comment 6

5 years ago
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.
Attachment #8334816 - Flags: review?(benjamin) → review+

Comment 7

5 years ago
Assignee: nobody → adw
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
You need to log in before you can comment on or make changes to this bug.