Closed Bug 816059 Opened 12 years ago Closed 12 years ago

Intermittent browser_bug812562.js | Test timed out (followed by several more timeouts)

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla20

People

(Reporter: emorley, Assigned: keeler)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

Rev3 Fedora 12 mozilla-inbound opt test mochitest-browser-chrome on 2012-11-28 00:55:38 PST for push 17683784d36b slave: talos-r3-fed-065 https://tbpl.mozilla.org/php/getParsedLog.php?id=17404544&tree=Mozilla-Inbound { TEST-START | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 1: Should have a click-to-play notification TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 1: plugin fallback type should be PLUGIN_VULNERABLE_UPDATABLE TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 1: plugin should not be activated TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 2: Should not have a click-to-play notification TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 2: Should not have a plugin in this page TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 4: Should have a click-to-play notification TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 4: plugin fallback type should be PLUGIN_VULNERABLE_UPDATABLE TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | test part 4: plugin should not be activated TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_bug812562.js | Test timed out } and then: { TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_clearplugindata.js | an unexpected uncaught JS exception reported through window.onerror - TypeError: p.setSitesWithDataCapabilities is not a function at http://mochi.test:8888/browser/browser/base/content/test/browser_clearplugindata.html:16 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_clearplugindata.js | Test timed out TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_clearplugindata.js | Found a tab after previous test timed out: http://mochi.test:8888/browser/browser/base/content/test/browser_clearplugindata.html TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginnotification.js | Test 8, plugin fallback type should be PLUGIN_CLICK_TO_PLAY - Got 9, expected 8 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginnotification.js | There should be a PluginClickToPlay event for each plugin that was blocked due to the plugins.click_to_play pref - Got 0, expected 5 TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_pluginnotification.js | Test 14, Plugin should be activated }
Attached patch patch (obsolete) (deleted) — Splinter Review
I think what's happening here is that my clever use of the blocklist is causing machines to actually make network requests during these tests, which we don't want to do. This patch should put things back to their proper state. Jared - if you would have a look, that'd be great.
Assignee: nobody → dkeeler
Status: NEW → ASSIGNED
Attachment #686670 - Flags: review?(jaws)
Thank you for looking at this :-)
Comment on attachment 686670 [details] [diff] [review] patch Review of attachment 686670 [details] [diff] [review]: ----------------------------------------------------------------- So the test framework sets a user preference when it starts up and the previous code never put back the original test preference when exiting? ::: browser/base/content/test/head.js @@ +211,5 @@ > Services.obs.addObserver(observer, "blocklist-updated", false); > blocklistNotifier.notify(null); > } > > +var _testBlocklistURL = null; I'd probably rename this to _originalTestBlocklistURL.
Attachment #686670 - Flags: review?(jaws) → review+
Attached patch patch v1.1 (deleted) — Splinter Review
For completeness, here's the updated patch that I checked in. Try run: https://tbpl.mozilla.org/?tree=Try&rev=fb4856dd4649 (I tried to get multiple browser-chrome tests to run on linux, but some of them are taking forever - I'm pretty confident this is the right thing to do, though.) Checkin: https://hg.mozilla.org/integration/mozilla-inbound/rev/abb39d1df815
Attachment #686670 - Attachment is obsolete: true
Attachment #686743 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: