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

RESOLVED FIXED in mozilla20

Status

()

Core
Plug-ins
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: emorley, Assigned: keeler)

Tracking

({intermittent-failure})

Trunk
mozilla20
x86
Linux
intermittent-failure
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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
}
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Comment hidden (Treeherder Robot)
Created attachment 686670 [details] [diff] [review]
patch

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)
(Reporter)

Comment 8

6 years ago
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+
Created attachment 686743 [details] [diff] [review]
patch v1.1

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+
https://hg.mozilla.org/mozilla-central/rev/abb39d1df815
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
You need to log in before you can comment on or make changes to this bug.