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)
Core
Graphics: WebRender
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)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•7 years ago
|
||
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.
Reporter | ||
Comment 2•7 years ago
|
||
Reporter | ||
Comment 3•7 years ago
|
||
(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.
Comment 4•7 years ago
|
||
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...
Comment 5•7 years ago
|
||
Similar issue for Activity Stream https://bugzilla.mozilla.org/show_bug.cgi?id=1454110 We use `BrowserTestUtils.openNewForegroundTab` for most of our tests.
Comment 10•7 years ago
|
||
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)
Updated•7 years ago
|
Component: General → Graphics: WebRender
Product: Firefox → Core
Comment 11•7 years ago
|
||
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)
Assignee | ||
Comment 12•7 years ago
|
||
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)
Assignee | ||
Comment 13•7 years ago
|
||
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
Comment 14•7 years ago
|
||
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)
Assignee | ||
Comment 15•7 years ago
|
||
(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.
Assignee | ||
Comment 16•7 years ago
|
||
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.
Updated•7 years ago
|
Blocks: stage-wr-trains
Priority: -- → P2
Assignee | ||
Comment 17•7 years ago
|
||
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → bugmail
Comment hidden (Intermittent Failures Robot) |
You need to log in
before you can comment on or make changes to this bug.
Description
•