Closed
Bug 937380
Opened 11 years ago
Closed 11 years ago
forgetaboutsite/test/browser/browser_clearplugindata.js fails when browser-chrome tests are split into chunks
Categories
(Toolkit :: Data Sanitization, defect)
Toolkit
Data Sanitization
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: jgriffin, Assigned: adw)
References
Details
Attachments
(1 file, 1 obsolete file)
1.34 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
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•11 years ago
|
||
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•11 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)
Comment 3•11 years ago
|
||
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.
Assignee | ||
Comment 4•11 years ago
|
||
Passes locally with this. Benjamin, would you mind reviewing?
Attachment #8334815 -
Flags: review?(benjamin)
Assignee | ||
Comment 5•11 years ago
|
||
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•11 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+
Assignee | ||
Comment 7•11 years ago
|
||
Assignee: nobody → adw
Status: NEW → ASSIGNED
Comment 8•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 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.
Description
•