1978675 - `./mach test` stalls on redirect.html as browser-test.js fails to read `testing.browserTestHarness.timeout` (on aarch64 Windows)

Status: RESOLVED FIXED

(Testing :: Mochitest, defect)

Description

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

testing.browserTestHarness.timeout seems to exist only when the relevant option is specified, but bug 1978111 started to read it unconditionally without specifying a default value. Thus browser-test.js throws at line 8.

 0:25.86 GECKO(21700) JavaScript error: chrome://mochikit/content/browser-test.js, line 8: NS_ERROR_UNEXPECTED: Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref]

Comment 1

[Florian Quèze [:florian]]

Which test were you trying to run? The code sets the test_timeout variables for the 'browser', 'chrome' and 'a11y' mochitest flavors: https://searchfox.org/mozilla-central/rev/146c8d8d1f3cf15be3c263808f9674a97752c41a/testing/mochitest/runtests.py#2476,2492-2495 Is there another one that I missed and that isn't running on CI?

Comment 2

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

It's mochitest. ./mach test dom/bindings/test fails.

Comment 3

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

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

Comment 4

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Actually maybe the cause is somewhere else?

 0:13.05 GECKO(33340) C:\Users\sasch\AppData\Local\Temp\tmpszs1nawg.mozrunner\user.js:235: prefs parse error: unexpected character

And line 235 has this:

user_pref("testing.browserTestHarness.timeout", 240.0);

Which seemingly is from

        if mozinfo.info["os"] == "win" and mozinfo.info["processor"] == "aarch64":
            test_timeout = self.DEFAULT_TIMEOUT * 4
            self.log.info(
                f"Increasing default timeout to {test_timeout} seconds (win aarch64)"
            )

where self.DEFALUT_TIMEOUT is 60.0. (Looks like the pref parser only supports integers, and yes I'm on aarch64 Windows.)

It seems so far it worked only because the test only conditionally read the value before bug 1978111:

    if (prefs.prefHasUserValue("testing.browserTestHarness.timeout")) {
      gTimeoutSeconds = prefs.getIntPref("testing.browserTestHarness.timeout");
    }

Comment 5

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Changing DEFALUT_TIMEOUT to 60 fixes the issue. But why do we not use DEFAULT_TIMEOUT elsewhere? 🤔

Comment 6

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

The special condition for aarch64 Windows is added 6 years ago from bug 1525743. Is that still needed, or can we drop it? (Are we using the same slow hardware on CI for aarch64 Windows?)

Comment 7

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Actually we don't even run tests on aarch64 Windows. Let's just drop it?

Comment 8

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Attachment: Bug 1978675 - No more longer timeout for aarch64 Windows r=florian

We don't run CI on such hardware.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/c646b6485bc1
https://hg.mozilla.org/integration/autoland/rev/cf1cfc3f970e
No more longer timeout for aarch64 Windows r=florian

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3b0afeffa6b0
https://hg.mozilla.org/integration/autoland/rev/d0da86afaa05
Revert "Bug 1978675 - No more longer timeout for aarch64 Windows r=florian" for causing mda failures on test_streams_element_capture_mediatrack.html

Comment 11

[Cristina Horotan [:chorotan]]

Backed out for causing mda failures on test_streams_element_capture_mediatrack.html

Backout link

Push with failures

Failure log

Comment 12

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Hello Cristina, this patch only affects Windows aarch64 which we don't really have in our CI, meaning zero effect on our CI. Probably the culprit is something else, like bug 1967793?

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/46d0f1f5418c
https://hg.mozilla.org/integration/autoland/rev/23a6a706ffa9
No more longer timeout for aarch64 Windows r=florian

Comment 14

[Cristina Horotan [:chorotan]]

I've relanded, will investigate further. Thanks

Comment 15

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/cf1cfc3f970e

Comment 16

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/23a6a706ffa9