1713890 - Relax pref reading constraints for browser_preferences_usage.js skipped in 'browser/base/content/test/performance/browser.ini' for Fission

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, task, P2)

Description

[Andrew Halberstadt [:ahal]]

The following tests were disabled in browser/base/content/test/performance/browser.ini due to new Fission platform triage:
browser_preferences_usage.js

Full diff:

diff --git a/browser/base/content/test/performance/browser.ini b/browser/base/content/test/performance/browser.ini
--- a/browser/base/content/test/performance/browser.ini
+++ b/browser/base/content/test/performance/browser.ini
@@ -20,16 +20,17 @@ prefs =
 support-files =
   head.js
 [browser_appmenu.js]
 skip-if = asan || debug || (os == 'win' && bits == 32) || (os == 'win' && processor == 'aarch64') # Bug 1382809, bug 1369959, Win32 because of intermittent OOM failures, bug 1533141 for aarch64
 [browser_preferences_usage.js]
 skip-if =
   !debug
   apple_catalina  # platform migration
+  os == 'win' && fission  # New platform triage
 [browser_startup.js]
 [browser_startup_content.js]
 skip-if = !e10s
 support-files =
   file_empty.html
 [browser_startup_content_subframe.js]
 skip-if = !fission
 support-files =

See the following try push for failures:
https://treeherder.mozilla.org/jobs?repo=try&revision=ad7a18fdad3b8e35b44152c16d94babb80387cd8

To run these failures in your own try push, first revert the skip-if
annotations, then run:

$ ./mach try fuzzy --rebuild 3 browser/base/content/test/performance/browser.ini

Then use the fuzzy interface to select the task(s) which are relevant to the
removed skip-if expression(s). Please note the failure may be intermittent
and/or been fixed since the triage took place.

Comment 1

[Chris Peterson [:cpeterson]]

We need to determine whether this browser-chrome test failure should block shipping Fission. Tracking for Fission Milestone M7a for the initial audit. Then we can decide whether to move this bug to Fission M8 or post-MVP (Fission Future).

Here is a recent Try run for Fission browser-chrome:

https://treeherder.mozilla.org/jobs?repo=try&revision=ad7a18fdad3b8e35b44152c16d94babb80387cd8

Comment 2

[Nika Layzell [:nika] (ni? for response)]

This failure appears to be caused by the fission process preallocator allocating (currently) 3 additional processes with Fission compared to Windows. These prefs are accessed twice during startup on windows (see bug 1639497), and with the slightly increased number of processes, the 101 call limit can easily be exceeded while running the test. The checks here (https://searchfox.org/mozilla-central/rev/74f3c420ee54001059e1850bef3be876749ff873/browser/base/content/test/performance/browser_preferences_usage.js#237-246) should probably be relaxed to 100..110 checks like the browzer.zoom.full test: https://searchfox.org/mozilla-central/rev/74f3c420ee54001059e1850bef3be876749ff873/browser/base/content/test/performance/browser_preferences_usage.js#201-204

Comment 3

[Chris Peterson [:cpeterson]]

(In reply to Nika Layzell [:nika] (ni? for response) from comment #2)

This failure appears to be caused by the fission process preallocator allocating (currently) 3 additional processes with Fission compared to Windows. These prefs are accessed twice during startup on windows (see bug 1639497), and with the slightly increased number of processes, the 101 call limit can easily be exceeded while running the test.

In that case, I'll move this bug to the DOM: Content Processes component.

Note that this test is also disabled for opt builds on all platforms, so it is already a flaky test.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1713890 - Relax gfx.{content,canvas}.asure.backends pref usage checks,

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/73f9850ba6ba
Relax gfx.{content,canvas}.asure.backends pref usage checks, r=mconley

Comment 6

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/73f9850ba6ba