Setting a pref in js/xpconnect/tests/unit/xpcshell.ini doesn't apply
Categories
(Core :: JavaScript Engine, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: mgaudet, Assigned: mgaudet)
References
Details
Attachments
(2 files)
1.79 KB,
patch
|
Details | Diff | Splinter Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
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•4 years ago
|
||
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.
Assignee | ||
Comment 2•4 years ago
|
||
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
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
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.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 5•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
bugherder |
Description
•