1763001 - Intermittent layout/base/tests/chrome/test_color_scheme_browser.xhtml | AbortError: Actor 'SpecialPowers' destroyed before query 'Spawn' was resolved - Should not throw any errors

Status: RESOLVED FIXED

(Core :: Layout, defect, P5)

Description

[Treeherder Bug Filer]

Filed by: mlaza [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer?job_id=373328635&repo=autoland
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SJmGhrG0S_u3guQG7bn8mA/runs/0/artifacts/public/logs/live_backing.log

---

task 2022-04-04T19:56:03.544Z] 19:56:03     INFO - Buffered messages finished
[task 2022-04-04T19:56:03.545Z] 19:56:03     INFO - TEST-UNEXPECTED-FAIL | layout/base/tests/chrome/test_color_scheme_browser.xhtml | AbortError: Actor 'SpecialPowers' destroyed before query 'Spawn' was resolved - Should not throw any errors
[task 2022-04-04T19:56:03.545Z] 19:56:03     INFO - add_task/nextTick/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:2103:26
[task 2022-04-04T19:56:03.545Z] 19:56:03     INFO - GECKO(5204) | [Child 9184, Main Thread] WARNING: '!CanSend() || !mManager || !mManager->CanSend()', file /builds/worker/checkouts/gecko/dom/ipc/jsactor/JSWindowActorChild.cpp:44
[task 2022-04-04T19:56:03.546Z] 19:56:03     INFO - GECKO(5204) | MEMORY STAT | vsize 2120972MB | vsizeMaxContiguous 65606854MB | residentFast 469MB | heapAllocated 208MB
[task 2022-04-04T19:56:03.546Z] 19:56:03     INFO - GECKO(5204) | [Parent 4592, Main Thread] WARNING: early callback, or time went backwards: '!aAllowIdleDispatch', file /builds/worker/checkouts/gecko/xpcom/threads/IdleTaskRunner.cpp:197
[task 2022-04-04T19:56:03.547Z] 19:56:03     INFO - TEST-OK | layout/base/tests/chrome/test_color_scheme_browser.xhtml | took 290ms

Comment 1

[Marian-Vasile Laza]

Retriggers & backfills: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&fromchange=dfaf887eaf6acd9263894272f31be0c07f726093&searchStr=windows%2C10%2Cx86%2C2004%2Cwebrender%2Cdebug%2Cmochitests%2Cwithout%2Ce10s%2Cor%2Cfission%2Ctest-windows10-32-2004-qr%2Fdebug-mochitest-chrome-1proc%2Cc1&tochange=8b11b00d98c23582cff9a255dc043f22ff82ec8b&selectedTaskRun=asucKAPTR3iYcRrKQRHCQA.0

It's a high freq failure, Emilio can you please take a look?

Comment 2

[Intermittent Failures Robot]

29 failures in 634 pushes (0.046 failures/push) were associated with this bug yesterday.

Repository breakdown:

• autoland: 29

Platform and build breakdown:

• windows10-32-2004-qr: 16
  • debug: 16
• linux1804-64-qr: 5
  • debug: 3
  • opt: 2
• windows10-64-2004-qr: 4
  • debug: 4
• linux1804-64-asan-qr: 1
  • opt: 1
• macosx1015-64-qr: 2
  • debug: 2
• windows10-64-2004-asan-qr: 1
  • opt: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1763001&startday=2022-04-04&endday=2022-04-04&tree=all

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Nika, it seems like remote browser elements don't block the load event, is that intentional?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1763001 - Manually wait for remote browser load in test_color_scheme_browser.xhtml. r=nika

Remote browsers don't block onload otherwise, so we could spawn a task
to the initial about:blank, and getting that replaced by the real load
before the task executed.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Maybe there's a better way than watching nsIWPL. Probably it should block the load event the same way fission iframes or non-remote browsers do, but I'll send a patch waiting for now.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Gijs, my patch is hitting a lint issue about:

Do not use add_task() for setup, use add_setup() instead.

But add_setup() is not defined in mochitest-chrome, apparently. I can workaround it by renaming the function, but maybe the lint needs to be tweaked? Or add_setup should become available to mochitest-chrome perhaps?

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/542bff487bbf
Manually wait for remote browser load in test_color_scheme_browser.xhtml. r=nika

Comment 8

[:Gijs (he/him)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

Gijs, my patch is hitting a lint issue about:

Do not use add_task() for setup, use add_setup() instead.

But add_setup() is not defined in mochitest-chrome, apparently.

Nor in mochitest-plain. mochitest-chrome and plain have their own add_task implementation, and would need their own add_setup implementation. After the browser mochitest ones, I already did the work for xpcshell implementation in bug 1757040 (for which the same is true). I'd be happy to help review something for mochitest-plain/chrome, but when I asked about mochitest-plain in #developers a while ago, the suggestion was that few tests get created these days and few use add_task at all, so it was bottom of my priority pile.

I can workaround it by renaming the function, but maybe the lint needs to be tweaked?

The lint is only applied to the browser mochitest environment. It sounds like the linter thinks this chrome test is a browser mochitest. This normally happens because multiple test flavours share the same directory.

In this case, it looks like the test is in layout/base/tests/chrome/, so I don't know why it's getting the browser mochitest environment at all. Mark - maybe https://searchfox.org/mozilla-central/rev/fbb1e8462ad82b0e76b5c13dd0d6280cfb69e68d/layout/base/tests/.eslintrc.js#3-5 needs fixing? Looks like there are browser tests directly in that directory, but of course not in the chrome subdirectory. I don't know how best to represent that in an .eslintrc file - can we override the env in the subdir entirely, instead of extending the existing env?

Comment 9

[Mark Banner (:standard8)]

(In reply to :Gijs (he/him) from comment #8)

In this case, it looks like the test is in layout/base/tests/chrome/, so I don't know why it's getting the browser mochitest environment at all. Mark - maybe https://searchfox.org/mozilla-central/rev/fbb1e8462ad82b0e76b5c13dd0d6280cfb69e68d/layout/base/tests/.eslintrc.js#3-5 needs fixing? Looks like there are browser tests directly in that directory, but of course not in the chrome subdirectory. I don't know how best to represent that in an .eslintrc file - can we override the env in the subdir entirely, instead of extending the existing env?

The problem is the mixture of test types in layout/base/tests/, that top directory has both browser.ini and mochitest.ini. As a result it needs to know about both environments via the .eslintrc.js file. We do have bug 1379669 for potentially changing how we apply the ESLint environments so that different test types could nicely sit in the same directory, but I have never got around to investigating how much of a performance hit that might be (or how complex).

I think the simplest solution here for our current situation would be to move the two types of tests into separate sub-directories. The only other option would be to only apply the environments to the particular files in the directory, but that feels like it would be harder for maintenance.

Comment 10

[:Gijs (he/him)]

(In reply to Mark Banner (:standard8) from comment #9)

(In reply to :Gijs (he/him) from comment #8)

In this case, it looks like the test is in layout/base/tests/chrome/, so I don't know why it's getting the browser mochitest environment at all. Mark - maybe https://searchfox.org/mozilla-central/rev/fbb1e8462ad82b0e76b5c13dd0d6280cfb69e68d/layout/base/tests/.eslintrc.js#3-5 needs fixing? Looks like there are browser tests directly in that directory, but of course not in the chrome subdirectory. I don't know how best to represent that in an .eslintrc file - can we override the env in the subdir entirely, instead of extending the existing env?

The problem is the mixture of test types in layout/base/tests/, that top directory has both browser.ini and mochitest.ini. As a result it needs to know about both environments via the .eslintrc.js file. We do have bug 1379669 for potentially changing how we apply the ESLint environments so that different test types could nicely sit in the same directory, but I have never got around to investigating how much of a performance hit that might be (or how complex).

I think the simplest solution here for our current situation would be to move the two types of tests into separate sub-directories. The only other option would be to only apply the environments to the particular files in the directory, but that feels like it would be harder for maintenance.

I'm sorry but I'm confused. The "offending" tests are not in layout/base/tests/, they are in layout/base/tests/chrome/. Can we add a new .eslintrc.js there that doesn't include the browser-test environment at all, overriding the existing .eslintrc.js file that is in layout/base/tests/ ? That wouldn't fix the existing issue inside layout/base/tests/ itself, but would help for the tests that are already in the chrome/ subdir, right?

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1762298

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/542bff487bbf

Comment 13

[Intermittent Failures Robot]

37 failures in 648 pushes (0.057 failures/push) were associated with this bug yesterday.

Repository breakdown:

• autoland: 34
• mozilla-central: 2
• try: 1

Platform and build breakdown:

• macosx1015-64-qr: 4
  • debug: 4
• windows10-64-2004-qr: 8
  • opt: 1
  • debug: 7
• windows10-32-2004-qr: 5
  • debug: 5
• windows10-64-2004-shippable-qr: 2
  • opt: 2
• linux1804-64-qr: 12
  • opt: 3
  • debug: 9
• linux1804-64-asan-qr: 4
  • opt: 4
• windows10-64-2004-asan-qr: 2
  • opt: 2

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1763001&startday=2022-04-05&endday=2022-04-05&tree=all

Comment 14

[Mark Banner (:standard8)]

(In reply to :Gijs (he/him) from comment #10)

I'm sorry but I'm confused. The "offending" tests are not in layout/base/tests/, they are in layout/base/tests/chrome/. Can we add a new .eslintrc.js there that doesn't include the browser-test environment at all, overriding the existing .eslintrc.js file that is in layout/base/tests/ ? That wouldn't fix the existing issue inside layout/base/tests/ itself, but would help for the tests that are already in the chrome/ subdir, right?

From an ESLint perspective, browser-test etc are configurations rather than environments - as well as setting environment variables, we also turn on/off various rules specific for those tests.

So when layout/base/tests/.eslintrc.js extends from the browser-test configuration, then that configuration applies to all the subdirectories of layout/base/tests. If there's another .eslintrc.js in the sub-tree, then it builds on top of the parent configurations rather than replacing them.

Unlike environments, we can't turn off configurations except for manually disabling all the rules etc.

Comment 15

[Mark Banner (:standard8)]

(In reply to Mark Banner (:standard8) from comment #14)

Unlike environments, we can't turn off configurations except for manually disabling all the rules etc.

Just had a thought, one option might be to set "mozilla/no-addtask-setup": "off", in chrome-test and mochitest-test. That would fix it for situations like this, though it would be ambiguous for if it was turned on or not in directories like layout/base/test where we have both mochitest-test and browser-test. I suspect the browser-test version would win in this case and turn it on, as that's listed second.

Comment 16

[Intermittent Failures Robot]

66 failures in 2922 pushes (0.023 failures/push) were associated with this bug in the last 7 days.

This is the #5 most frequent failure this week.

** This failure happened more than 30 times this week! Resolving this bug is a high priority. **

** Try to resolve this bug as soon as possible. If unresolved for 2 weeks, the affected test(s) may be disabled. **

Repository breakdown:

• autoland: 63
• mozilla-central: 2
• try: 1

Platform and build breakdown:

• linux1804-64-qr: 17
  • debug: 12
  • opt: 5
• windows10-64-2004-qr: 12
  • debug: 11
  • opt: 1
• linux1804-64-asan-qr: 5
  • opt: 5
• macosx1015-64-qr: 6
  • debug: 6
• windows10-32-2004-qr: 21
  • debug: 21
• windows10-64-2004-asan-qr: 3
  • opt: 3
• windows10-64-2004-shippable-qr: 2
  • opt: 2

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1763001&startday=2022-04-04&endday=2022-04-10&tree=all