1654286 - Setting a pref in js/xpconnect/tests/unit/xpcshell.ini doesn't apply

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Matthew Gaudet (he/him) [:mgaudet]]

Applying the following patch

diff --git a/js/xpconnect/tests/unit/xpcshell.ini b/js/xpconnect/tests/unit/xpcshell.ini
--- a/js/xpconnect/tests/unit/xpcshell.ini
+++ b/js/xpconnect/tests/unit/xpcshell.ini
@@ -20,6 +20,8 @@ support-files =
   recursive_importB.jsm
   syntax_error.jsm
   uninitialized_lexical.jsm
+prefs =
+  javascript.options.experimental.private_fields=true
 
 [test_allowWaivers.js]

I would expect running ./mach xpcshell-test --headless js/xpconnect/tests/unit/test_private_field_xrays.js to execute the code path for private fields; however, it does not.

(If the test were running the private field code, you'd see output from Assert.throws about type errors. You do not however, you see

 0:01.56 INFO (xpcshell/head.js) | test pending (2)
 0:01.71 PASS  - true == true
 0:01.72 PASS  - true == true

as the only test output. )

It's possible this is the same bug as Bug 1654274, but figured I ought to have this opened separately as another symptom I encountered.

Comment 1

[Geoff Brown [:gbrown]]

Setting prefs in xpcshell manifests is an under-utilized feature, but there are a few such cases, and the affected tests appear to be passing in automation.

https://searchfox.org/mozilla-central/rev/3b6958c26049c1e27b2790a43154caaba9f6dd4a/dom/workers/test/xpcshell/xpcshell.ini#18
https://searchfox.org/mozilla-central/rev/3b6958c26049c1e27b2790a43154caaba9f6dd4a/toolkit/components/extensions/test/xpcshell/xpcshell.ini#15

These test manifests also pass when I run them with 'mach xpcshell-test <dir>', on Linux.

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: unconditional.patch

Hmm. Something else might be going on here then...

If I apply the attached patch and run, I get a test failure because the syntax isn't enabled; yet, the harness does seem to be seeing the pref!

matthew@xtower:~/unified$ ./mach xpcshell-test --headless js/xpconnect/tests/unit/test_private_field_xrays.js
 0:00.43 INFO js/xpconnect/tests/unit/test_private_field_xrays.js: Per-test extra prefs will be set:
  javascript.options.experimental.private_fields=true
 0:00.44 TEST_START: js/xpconnect/tests/unit/test_private_field_xrays.js
 0:00.44 INFO js/xpconnect/tests/unit/test_private_field_xrays.js | full c

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

Ok: Some printf debugging suggests this isn't a problem with the shell directly at least. Somehow we're reading the prefs twice, and the first time we read it, the pref is false (and so disabled), and the second time we read it, the pref is true. But, by that time the realm is already created, and so the realm of interest is never updated.

We need to make this a preference that can be updated somehow; probably converting it to a context option.

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

Attachment: Bug 1654286 - Convert private fields option to a JSContext option r?tcampbell

This avoids the issue where xpcshell appears to startup, create a realm, then
read preferences. Prior to this patch, by the time the prefs were read, it was
too late for the realm creation option to take effect. This way, we update the
realm option.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cc4f3412856d
Convert private fields option to a JSContext option r=jandem

Comment 7

[Cristina Coroiu [:ccoroiu]]

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