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

RESOLVED FIXED in mozilla28

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jgriffin, Assigned: adw)

Tracking

unspecified
mozilla28
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

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

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

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

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

Comment 7

5 years ago
https://hg.mozilla.org/integration/fx-team/rev/15e0829b8c48
Assignee: nobody → adw
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/15e0829b8c48
Status: ASSIGNED → RESOLVED
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.