Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 12:02 AM Henri Sivonen wrote: > If in a plain mochitest I do > var rope = > SpecialPowers.Cu.getJSTestingFunctions().newRope(t.head, t.tail); > var encoded = (new TextEncoder()).encode(rope); > the encode() method doesn't see the rope. Instead, the call to > encode() sees a linear string that was materialized by a copy in a > cross-compartment wrapper. > > Does SpecialPowers always introduce a compartment boundary in a plain > mochitest? For posterity: It does. Components.utils can't be exposed to an unprivileged content compartment directly. > In what type of test does > SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a > rope within the calling compartment such that passing the rope to a > WebIDL API really makes the rope enter the WebIDL bindings instead of > getting intercepted by a cross-compartment wrapper first? > > Alternatively: What kind of string lengths should I use with normal JS > string concatenation to be sure that I get a rope instead of the right > operand getting copied into an extensible left operand? > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 1:37 PM Jan de Mooij wrote: > > On Mon, Aug 26, 2019 at 12:25 PM Henri Sivonen wrote: >> >> Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there >> another way to reach JS testing functions from there? > > > I think just Cu.getJSTestingFunctions() should work. Thanks. This worked. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 12:25 PM Henri Sivonen wrote: > Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there > another way to reach JS testing functions from there? > I think just Cu.getJSTestingFunctions() should work. Jan > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 11:27 AM Jan de Mooij wrote: > > On Mon, Aug 26, 2019 at 9:02 AM Henri Sivonen wrote: >> >> In what type of test does >> SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a >> rope within the calling compartment such that passing the rope to a >> WebIDL API really makes the rope enter the WebIDL bindings instead of >> getting intercepted by a cross-compartment wrapper first? > > > An xpcshell test or mochitest-chrome is probably easiest Thanks. Since SpecialPowers doesn't exist in xpcshell tests, is there another way to reach JS testing functions from there? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: JS testing functions and compartments in mochitest-plain
On Mon, Aug 26, 2019 at 9:02 AM Henri Sivonen wrote: > In what type of test does > SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a > rope within the calling compartment such that passing the rope to a > WebIDL API really makes the rope enter the WebIDL bindings instead of > getting intercepted by a cross-compartment wrapper first? > An xpcshell test or mochitest-chrome is probably easiest.. Or a system Sandbox/evalInSandbox but that becomes more complicated. Strings are copied across zone boundaries so any global in the system zone should work. You can use the isSameCompartment JS testing function to test/assert the following is true in your test: testingFunctions.isSameCompartment(testingFunctions.newRope, this) (same-compartment is a stronger invariant than same-zone but for system compartments it should be fine). > Alternatively: What kind of string lengths should I use with normal JS > string concatenation to be sure that I get a rope instead of the right > operand getting copied into an extensible left operand? > js::ConcatStrings creates a rope if both sides have length > 0 and the result doesn't fit in a JSFatInlineString (limits there are 11 and 23 for Latin1 vs TwoByte chars). The extensible-string optimization applies to rope flattening (we still create a rope first in that case). Hope this helps, Jan > > -- > Henri Sivonen > hsivo...@mozilla.com > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
JS testing functions and compartments in mochitest-plain
If in a plain mochitest I do var rope = SpecialPowers.Cu.getJSTestingFunctions().newRope(t.head, t.tail); var encoded = (new TextEncoder()).encode(rope); the encode() method doesn't see the rope. Instead, the call to encode() sees a linear string that was materialized by a copy in a cross-compartment wrapper. Does SpecialPowers always introduce a compartment boundary in a plain mochitest? In what type of test does SpecialPowers.Cu.getJSTestingFunctions().newRope() actually return a rope within the calling compartment such that passing the rope to a WebIDL API really makes the rope enter the WebIDL bindings instead of getting intercepted by a cross-compartment wrapper first? Alternatively: What kind of string lengths should I use with normal JS string concatenation to be sure that I get a rope instead of the right operand getting copied into an extensible left operand? -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
