Closed Bug 1454531 Opened 7 years ago Closed 7 years ago

QuantumRender (qr) browser_*.js perma "Test timed out" in test-verify-e10s (TV) for BrowserTestUtils.withNewTab/openNewForegroundTab due to no TabSwitchDone event

Categories

(Core :: Graphics: WebRender, defect, P2)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: MattN, Assigned: kats)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: intermittent-failure, reproducible, Whiteboard: [wr][triage] )

Attachments

(1 file)

BrowserTestUtils tab helpers used for mochitest-browser-chrome tests are causing test-verify-e10s (TV) perma-fails with QuantumRender enabled on both macOS and linux64 (opt and debug). The issue affects BrowserTestUtils.openNewForegroundTab which is used by BrowserTestUtils.withNewTab. Reproducible examples: * bug 1454333 > MOZ_WEBRENDER=1 MOZ_ACCELERATED=1 ./mach mochitest browser/base/content/test/urlbar/browser_search_favicon.js --verify * bug 1428472 comment 8 > MOZ_WEBRENDER=1 MOZ_ACCELERATED=1 ./mach mochitest toolkit/components/payments/test/browser/browser_change_shipping.js --verify Probably any tests using `BrowserTestUtils.withNewTab` or `BrowserTestUtils.openNewForegroundTab` are affected. Other potential candidates: https://bit.ly/2vnm6FE The issue seems to be that `BrowserTestUtils.switchTab` never receives the `TabSwitchDone` event while AsyncTabSwitcher gets stuck repeatedly running onUnloadTimeout (visible via --setpref browser.tabs.remote.logSwitchTiming=true). I'm not sure if the bug is in AsyncTabSwitcher or QuantumRender though.
This might be caused by bug 1437036, but that's just a guess based on how it sounds kind of similar to the other issues caused by that bug (see the dependencies). There's a patch there you can apply to see if it helps.
Attached patch Debug logging patch (deleted) — Splinter Review
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1) > This might be caused by bug 1437036, but that's just a guess based on how it > sounds kind of similar to the other issues caused by that bug (see the > dependencies). There's a patch there you can apply to see if it helps. Unfortunately https://hg.mozilla.org/try/rev/65c4531ccaee3dac80cf8e17e3d2ada667080b48 doesn't seem to fix the problem.
We have been trying to figure out the same issue which is preventing landing bug 1252998... https://treeherder.mozilla.org/#/jobs?repo=try&revision=d07c9490b5e5757af316f4f15dc8a9d5a2f22d7d&selectedJob=173468539 It looks like more people are starting to hit this, it seems pretty important to fix...
Similar issue for Activity Stream https://bugzilla.mozilla.org/show_bug.cgi?id=1454110 We use `BrowserTestUtils.openNewForegroundTab` for most of our tests.
Blocks: 1454110
Blocks: 1454776
Blocks: 1454856
Can we please disable TV on QuantumRender? This is piling up duplicates and I can imagine that there are still some people out there who haven't heard of this bug and spend a lot of time debugging because they think their own tests are failing (like me). We might want to consider not turning on TV on preffed off/experimental platforms at all. Running TV on the main configurations sounds totally sufficient to me.
Flags: needinfo?(jmaher)
Flags: needinfo?(bugmail)
Component: General → Graphics: WebRender
Product: Firefox → Core
at some point in time we will need to make QR tier-1 and running all the tests- progress is made every week towards that. test-verify (TV) is tier-2 and typically gives a great indication to "if the test is stable"- we have many cases where we ignore it and the test is a high frequency intermittent test failure. We just enabled TV for QR in bug 1453478, maybe we back that out and reland in a few weeks?
Flags: needinfo?(jmaher)
We don't run browser-chrome mochitest suites on QR, so why is TV running these tests? Ideally it should be able to figure out that the test is "disabled" on QR based on the taskcluster configs. Or is that not the case?
Flags: needinfo?(bugmail) → needinfo?(jmaher)
Note that QR has its own test set at [1] that excludes mochitest-browser-chrome. However if it helps I can remove this test set, use the common-tests set, and update the mochitest-browser-chrome task definition with an empty run-on-projects set for QR. If TV would skip running browser-chrome tests in that situation it might be preferable. [1] https://searchfox.org/mozilla-central/rev/59a9a86553e9bfd9277202748ff791fd9bc0713b/taskcluster/ci/test/test-sets.yml#105
test-verify looks at the *.ini manifests in tree to determine which tests are disabled. We would have to figure out a solution for determining if test jobs are enabled on a specific platform. It is probably doable, but I don't see an easy solution. I filed bug 1455309 to track working on test-verify. There are 4 bugs in progress right now on test-verify, when those are done, I can imagine this could be picked up next. :kats- given the fact that this is not something that is currently supported or easily hacked, I would recommend turning off the TV jobs for QR builds.
Flags: needinfo?(jmaher)
(In reply to Joel Maher ( :jmaher) (UTC-5) from comment #14) > :kats- given the fact that this is not something that is currently supported > or easily hacked, I would recommend turning off the TV jobs for QR builds. Yeah, fair enough. I'll write up the patch.
I backed out bug 1453478, which turned on the test-verify jobs. https://hg.mozilla.org/integration/mozilla-inbound/rev/1f7eb198c7e1590d1a4801906f93c0014a094e72 Will close this once it merges to m-c.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Assignee: nobody → bugmail
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: